How to Build an Agentic OS That Actually Does Something

An agentic OS is one dashboard that fronts every AI tool you already use, so you stop switching between ten tabs to get one job done. Almost every one of these builds you see online looks beautiful and does nothing. The screenshots are gorgeous. The buttons go nowhere. This guide walks through the opposite: the decisions that turn a nice-looking shell into something you open every morning because it saves you time.

The build in the video opens on a home screen with a clock, a live Gmail inbox, and a knowledge-graph view of a whole second brain. That graph searches every note you own. In the walkthrough it pulls back a business partner's company history in seconds. It reads beautifully in a demo.

The widgets that earn their place are the ones that finish a job rather than display a fact. The same build has four of those, and they are the reason the thing gets opened at all.

• A one-click skill launcher, so the skill you reach for every day is one button instead of a folder hunt. It can also browse every skill already on your machine.
• An offer generator that reads your knowledge base and fills in who the product is for, what outcome it promises, and what blocks people from getting there, then drafts the headline and the results table.
• A chat panel with a model switcher, so you can move between Codex, Astra, and Claude in one window and keep the full history of every conversation.
• A routines and run-history view, so every scheduled agent, every skill output, and every draft you generated is still there tomorrow.

The honest test for any widget is whether deleting it would cost you a real minute of your day. A clock fails that test and stays anyway, because one or two decorative pieces make the page feel like a place. Ten of them make it a poster.

Here is the part most people get backwards. In the video the new widget is not specified. It is described. The brief is roughly: add a YouTube analytics tracker to this screen, probably top right, maybe subscriber count, maybe recent videos, maybe views over the last 28 days, maybe a selector to change the time range, maybe revenue, and what else do you think would be valuable here? Then it gets sent.

That is not laziness. A vague brief with a clear outcome gives the model room to propose the parts you did not think to ask for, and it costs you nothing to delete the ones you do not want. A tight brief gets you exactly what you specified, which is capped at what you already knew.

We keep the exact brief wording and the finished widget specs inside Claude Code Club, because the copy-paste versions are the part that saves you the afternoon. The method above is the whole method, and you can run it by hand today.

The walkthrough uses YouTube for the demo for one reason: the YouTube Data API is free, so anyone following along can finish it. It is slightly technical and it is not hard.

1. 1Go to console.cloud.google.com and sign in with the account tied to your channel.
2. 2Create a new project. Give it a plain name like AIOS test. Skip the organization field.
3. 3Wait for it to finish, then check the project picker and make sure the new project is the one selected.
4. 4Open the main menu, go to APIs and Services, then Library.
5. 5Search for YouTube Data API v3, open it, and click Enable.
6. 6While you are in the Library, enable Gmail and Google Sheets too, so you do not come back here in a week.
7. 7Go to Credentials, click Create credentials, and choose API key.
8. 8Restrict that key to the YouTube API before you leave the page.

One detail worth knowing: the key is not limited to your own channel. You can pull public analytics for other channels too, which makes the same widget a competitor tracker the moment you want one. It is free to enable and needs no payment method, so you can finish the whole loop today.

An environment file is a plain text file of secrets that lives on your machine and never leaves it. Your tools read from it. Nothing uploads it. On a Mac, the one Codex reads sits inside a hidden folder in your home directory.

• Open your home folder in Finder and press shift, command, and period together. Hidden folders appear.
• Open the .codex folder. Inside it there is a .env file.
• Add one new line with a name and your key, then save and close the file.
• Codex now has access to that key everywhere, and so does every widget you build on top of it.

Once that is saved, the widget goes live. In the video it comes back reading 87.2k subscribers and 16 million all-time views, with the most recent uploads listed underneath and a collapse control so the panel folds away when it is not needed. Vanity numbers are fine on a dashboard, as long as the dashboard also does work.

The second upgrade in the video is a generation studio: the panel that fronts third-party image and video platforms so you can make an asset without leaving the OS. It worked, and it was wrong in three specific ways. Fixing it shows the whole review method in miniature.

Rather than describing the target in words, the walkthrough takes a screenshot of Higgsfield's own interface and hands it over with a short instruction: build something with the same functionality as this reference. Aspect ratio, quality, resolution, how many images to make, a prompt field, a reference image slot.

What comes back is a dark glass overlay split into two zones. Create holds the prompt and the generation settings. Library holds images, videos, and favorites, with the ability to reuse a past image as a reference and reopen the exact prompt and settings behind it. A screenshot carries more usable detail in one file than four paragraphs of careful description.

This is the idea worth taking away even if you never build an OS. The brief was deliberately loose, so almost none of the steering happened in the original prompt. All of it happened in the rejections afterwards.

• Not a new window. Clicking the studio launched a separate browser window, which breaks the entire point of working from one place. It needed to be a popup overlay on top of the page you were already on.
• Not at the top. The first layout put the prompt input at the top of the panel. Claude and ChatGPT both put the input at the bottom, so every person who has used either one is instantly disoriented by a box in the wrong place.
• Not a second login. The studio asked for a Higgsfield login even though the Higgsfield plugin was already connected to Codex. The fix is to have the system detect the connectors that are already there and use them.

None of those three are things you would think to put in a brief. All three are obvious the moment you use the thing. Taste gets applied in review, not in the brief, which means your job is to use what comes back rather than to imagine it in advance.

The practical version: send a loose brief, open what comes back, and use it for a minute with your hands rather than reading the code. Write down every moment of friction as a plain sentence. Send those sentences back. Repeat. Three rounds of that beats one perfect prompt every time.

The YouTube widget in the video is not built as a permanent feature. It is built as a module: a self-contained package you drop in if you use YouTube and leave out if you do not. That framing is the structural decision the whole build rests on.

There is no single right stack, and the tools that matter to you almost certainly are not the tools that matter to the next person. So the core ships useful out of the box, and everything beyond the core arrives as an add-on somebody chooses.

• Post on YouTube? Plug in the YouTube module.
• Run everything through Instagram instead? Swap it for the Instagram module.
• Living in Salesforce, Meta Ads, or GoHighLevel? Those become modules too.
• Selling physical product? A whole e-commerce section can arrive as one add-on pack.
• Anything Claude Code or Codex can connect to can become a widget. Anything you do not use, you hide.

The design question is not what should this do, it is what should this do for everybody, with the rest sold or shipped separately. The video makes the business logic explicit: if the goal were to make as much money as possible from this build, the modules would be sold as a marketplace and the core would be the free thing that gets people in the door.

That is how we ship it too. The starter kit for this build goes out to everyone in the club for $9 a month, and the module packs land on top of it as premium upgrades, so you start from a working core rather than a blank screen.

The person building this worked as an art director at Apple and did user experience work at PlayStation and Nissan, and the rule that carries over is boring and absolute: go through your own product step by step, as a real user, before you hand it to anyone.

The reason is simple. The moment something does not work, people leave. They do not file a bug report. They do not email you. They close the tab, they decide the product is not for them, and they tell other people. You get one pass at a first impression and you spend it without knowing.

Four failures show up in the video itself, which is the useful thing about watching someone build live rather than reading a finished writeup. Each one has a fix.

• Permission fatigue. The first time you use the system it asks to check file paths, read memory, open notes, over and over. There is no always allow option. Decide up front which folders the system is allowed to read, grant those once at the config level, and stop approving the same request over and over.
• The new-window problem. A feature that opens in a separate window has quietly cancelled the reason the OS exists. Default every sub-screen to an overlay on the page you are already on.
• The second-login problem. If a connector is already authorized at the Codex or Claude Code level, the widget should detect it and use it. Being asked to sign in to a service you are already signed in to reads as broken, even when it works.
• Silent generation. An image request that returns nothing looks like a crash. The panel has to poll the provider, keep asking is it ready yet, and show progress while it waits, then drop the result into the Library when it lands.

The fourth one is the one people skip, because a request that succeeds on the developer's fast machine looks instant. Anything that does not return instantly needs a visible waiting state, or people assume it is broken and click it again.

The build in the video is called an MVP out loud, which means a minimum viable product: the smallest version that is genuinely useful to somebody else. It gets handed to a community in that state, deliberately, with a note saying start here and build it out yourself.

The pattern it avoids is the common one. Somebody sits alone for months, builds the thing they personally want, polishes it, releases it to an audience that does not exist, and then wonders why nobody buys. The build is not the problem. Building for yourself instead of for a market is the problem.

Here is the shortest honest path from reading this to having a working widget on a screen you own. Set aside about ninety minutes.

1. 1Pick one number you actually look up by hand every week. Subscriber count, inbox volume, ad spend, open deals. One number, not five.
2. 2Create a Google Cloud project, enable the YouTube Data API v3, and enable Gmail and Sheets while you are in the Library.
3. 3Create an API key, restrict it to the YouTube API, and add it to the .env file in your .codex folder.
4. 4Write a loose brief: what you want to see, roughly where it goes, and the question about what else would be valuable.
5. 5Let the model propose the spec. Do not correct it before you see it.
6. 6Open the result and use it for one full minute with your hands. Do not read the code.
7. 7Write down every moment of friction as a plain sentence and send that list back as your second brief.
8. 8Repeat steps six and seven once more, then stop. Two review rounds gets you most of the way.
9. 9Send it to one person who is not you and watch them use it without helping.
10. 10Fix only what made them hesitate, then move on to the next module.

The point of the deadline is that a widget you finished today teaches you more than a dashboard you are still designing next month. When it works, the next module takes half as long, because the hard part was never the code.