Nask OS: I Built My Company an Operating System. The AI Stopped Sounding Like Everyone Else's.

I did not set out to build an operating system. I set out to stop answering the same question four times a week.

Every one of those questions had the same shape. What did that client actually ask for on the call. Which version of the creative went live. Did anyone reply to the thread from Tuesday. None of it was hard. All of it was somewhere. The answer existed in a recording, a message, a folder or an ad account, and the only thing standing between the question and the answer was a person willing to go and look in four places.

That person was me. Then it was my process. Now it is software. I call it Nask OS, it lives in my browser’s new tab, and this is what it looked like today at 4:41 in the afternoon, with client names swapped for letters and the money blurred:

Everything in this article is how that screen came to exist. The rest of the screens are at the bottom.

The integration layer in your company is a human being

Here is the diagram I draw on a whiteboard almost every week, badly, before someone politely asks me to stop drawing.

• Ad accountholds what ran
• CRMholds who replied
• Call recorderholds what they said
• Slackholds what changed
• Driveholds the file
• Project boardholds who owns it
• Six sources of truth. None of them talks to the other five.

Six tools. Six sources of truth. Each one excellent at its job and completely uninterested in the other five. Between them, a person: walking out to the ad account for what ran, out to the call recording for what was said, out to the CRM for who replied, and carrying fragments back to the middle.

That person is the aggregator. That is the actual architecture of most companies, and it works right up until the moment it does not, because the carrier is a human. Humans drop things. They remember the objection but not which call it was on. They go to sleep. They take the context with them when they leave, and no exit interview has ever successfully extracted it.

The tools are not the problem. The walking is the problem.

Do not rebuild the tools. Build the two floors above them.

The first instinct of every technical founder is to look at that mess and decide the answer is to build one thing that does all of it. I have that instinct too, and I have watched it eat entire years.

You are not going to beat Asana. Asana costs you a hundred and fifty a month and has a product team. More importantly, it has a security team, and a company terrified of what a breach would do to it. That fear is a feature you are renting. The version you assemble over three weekends has no such fear, and if it leaks your customer data the person explaining that to a regulator is you.

So keep paying them. Build upward instead.

Floor 3 · the interface

Draft the replyWhat did they ask for?Brief this week's ads

or just ask it anything

Floor 2 · the aggregator

Your databaseConnectorsOne key per person

Everything above reads from here. Nothing above talks to a tool directly.

Floor 1 · what you already pay for

Ad accountCRMCallsSlackDriveBoard

×Rebuild the tools yourselfTwo years, one worse Slack, and a breach you are personally liable for

Floor one is what you already have. Floor two is the aggregator: a database you control, a set of connectors that pull from each tool, and a key per person so access is granted and revoked rather than assumed. Floor three is the interface, which for me is a chat box plus a row of shortcut buttons for the questions that get asked constantly. Nask OS lives in a Chrome extension that has replaced my new tab page, which means the company’s brain is behind every tab I open. That is a personal quirk, not a requirement. What matters is that there is exactly one place to ask, and it sits above everything.

The connective tissue in my build is MCP, which is what lets an AI reach into a system, read what it needs, and act. It is unglamorous plumbing and it is the whole trick. Once the plumbing is in, the intelligence layer is almost an afterthought.

Generic AI output is a context problem, not a prompt problem

This is the part that matters for marketing, so I am going to be blunt about it.

Everyone has now had the experience of asking a model to write something for their business and receiving fluent, confident, weightless text. The reflex is to blame the prompt. People buy prompt courses. They add “act as a world-class copywriter” and are disappointed again.

The prompt was never the problem.

AI on its own

"Reply to this customer."

Thanks so much for reaching out!We really value your feedback andwe're looking into this for you.Please let us know if there isanything else we can help with.

Names nothing. Could be any company, any customer, any week.

AI on the company OS

"Reply to this customer."

You flagged the same delivery gap onthe 12 Aug call, and it is fixed:the March cohort ships Thursday.The ad you asked about is the oneyour own customer wrote in review 41.

Call, 12 Aug, 00:31:08Ticket #2214Review 41Ad set, week 34

Look at what actually changes between those two panels. Same model, same instruction. The left one is polite and says nothing because it knows nothing. The right one names a call, a date, a shipping week and a customer’s own review, because it can read the company. It is not more creative. It is better informed.

Authenticity in marketing is not a tone. You cannot prompt your way to it and you certainly cannot buy it in a template. Authenticity is having something specific to say, and specifics are facts: the exact phrase a customer used on a sales call, the objection that came up in eleven of the last twenty conversations, the feature nobody mentions in the pitch but everyone mentions in the reviews.

Every one of those facts already exists inside your company. Right now they are spread across a call recorder, a support inbox, a review platform and someone’s memory of a conversation in March. That is the entire reason your marketing sounds like everybody else’s: not because the writer is bad, but because the writer, human or otherwise, is working from the only material available to them, which is the internet’s average opinion about your category.

The aggregator is what turns your company’s own record into material. That is what it is for. The ads are downstream.

I have written elsewhere about what happens once you can produce creative at volume, and volume is genuinely the bigger lever on spend. But volume without grounding just gets you to the wrong answer faster and in more formats. The OS is the part that makes the hundred ads about your actual business.

What it feels like when the system is already running

The moment people understand this is never the architecture diagram. It is the first time work arrives before they asked for it.

Sales call, 52 min

live

1. min 04Transcript starts streaming
2. min 18The objection is recognised and matched to three past calls
3. min 31The follow-up is drafted, with the numbers already in it
4. min 47It is on your desk. The call is still running.

0of your attention spent on it, spread across zero interruptions

A recording lands. That is the trigger. Nothing else happens because a person remembered: a routine that was written once reads the transcript, recognises what was actually being discussed, pulls the matching history, and drafts what comes next. By the time the conversation ends, the follow-up is written, with the numbers already in it.

The reaction is always the same, and it is always some version of “wait, when did you do that?” The answer is weeks ago, once. Every run after that is free.

The task at the top of the Work screenshot below has an AUTO tag on it. I did not write that task. The OS noticed that a client had been paused for two weeks with no decision recorded either way, and wrote “Decide: restart or churn” at the top of my list, with the reason underneath. That is the whole idea in one line: the system holds the awkward question so I cannot quietly not have it.

That is the real return, and it is not the drafting. It is that the work stopped depending on somebody’s attention. Attention is the scarcest thing in a small company and it is spent almost entirely on remembering that things exist.

The routine nobody has to remember

Once the aggregator is there, the interesting things you can build stop being chat and start being routines that run whether or not anyone is thinking about them.

Relationship health, computed nightly

Account A0Replies fast, results on plan

Account B0Healthy, one open question 3 days old

Account C0Asked the same thing twice. Nobody answered.

Account D0Quiet, but the numbers are climbing

Account C, 11 days quiet. Flagged before anyone noticed, which is the only time flagging one is worth anything.

That one reads every message that passed through the system and scores the health of each relationship, on results and on the relationship itself, separately. It costs nothing to run because the data was already going to be there.

Full disclosure: I built that and have not switched it on yet. It has been sitting a month. Which is, if you want the honest version, an excellent demonstration of the problem it solves, since the account quietly going cold is never the one making enough noise to get on my list.

Build it in the stupidest possible order

The reason most of these projects die is not technical. It is that someone specced the whole cathedral, and nothing was usable until all of it was.

1

2

3

4

5

1. week 1Pull one sourceThe messiest one. Read-only. Nothing else.
2. week 2Pull a secondNow you have a join, and the first thing neither tool could answer.
3. week 3Write the logicThe rules you apply by hand today, written down once.
4. week 4Point AI at itOne question, one answer, with its sources shown.
5. week 5Give out the keysOne per person, revocable, logged.

One source. Read-only. Pick the messiest tool, the one where things get lost, not the tidiest. That first step is boring and it is worth doing alone, because at the end of it you can already ask one question you could not ask before.

Then a second source, and something more interesting happens: you now have a join. You can answer a question neither tool could answer on its own, which is the first moment the thing justifies itself.

Then the logic. Not AI yet. Just the rules you already apply by hand, written down once so they stop being tribal knowledge.

Then point the AI at it, and make it show its sources every time. An answer you cannot trace is worse than no answer, because it is confidently wrong at scale.

Then keys, one per person, revocable and logged. Do this before anyone else touches it, not after.

Five steps. A week each is a realistic pace next to a real job. Every step leaves something behind that works on its own, which means the project survives you losing interest in it, and you will lose interest in it at least once.

The bit where I argue against myself

I coach founders through this build, so it would be convenient for me to tell you that every founder should learn to build. I do not quite believe that.

You should learn enough to know what is possible. That is not optional any more. You cannot brief a developer, hire an engineer, or judge whether a quote is fair for a capability you have never seen work with your own hands. The vocabulary matters. The instinct for what is a two-hour job and what is a two-month job matters more.

But there is a failure mode on the other side, and it is seductive. Building this is genuinely fun. The feedback loop is fast, the AI makes you feel unreasonably capable, and it is much more pleasant than selling. Three months disappear. The internal tool gets beautiful and the pipeline gets thin.

So set the exit condition before you start, not after. You are learning enough to specify it, not enough to own it forever. When you can describe the aggregator, the interface and the access model to a developer clearly enough that they push back on details rather than ask you what you mean, you are done. Hand it over.

The other thing I have watched happen, repeatedly, is that founders who learn this stop being able to delegate it, because the round trip to another human, with its meetings and its overnight gaps, starts to feel unbearably slow next to just doing it. That is a real problem and it arrives later. It is a much better problem than the one you have now.

This is what it looks like when it is built

Not a mock-up, not a Figma file, not a diagram of what could exist. Nask OS, my new tab, on 7 September 2026, with names replaced by letters and money blurred. Nothing else touched.