What If Your Best People Were in Every Room?
How an enterprise builds an AI workforce from the talent it already has. (Part 1 of a series.)
The person everyone walks over to
Every company has one. Not the loudest or most senior — the person everyone quietly walks over to when something matters. Not because they know the most, but because they get it: they understand what the company stands for and steer things the right way.
The trouble is, they can only be in one room at a time.
What if their best instincts could sit beside every teammate at once — and everyone shared the best of themselves in return?
Over the past year, across three teams, I watched it happen.
Everyone grows up the same way
Nobody starts with an “AI strategy.” One team ran a ten-year-old app on a single VM. Another used AI licenses like a fancier Google. Each grew through the same stages, in order — from a first prompt in a browser to an orchestrated workforce. You don’t skip childhood, and no team skipped a stage.
How engineers grow up with AI — from a prompt in the browser to a coworker in the room. We grow with the tool; we're not replaced by it.
But growing up this way created a good problem: once everyone had agents, every agent was different — each shaped by its owner’s habits. Powerful, but unaligned.
Share the recipe, keep the cook
Your best chef can stand at one stove. Their recipe can be in every kitchen at once.
So each person's best instinct is pooled into one shared memory built on the best models, then shared back to everyone. Good new habits flow up; the upgraded team flows back down.
We weren't replacing anyone. We were sharing the judgment you already trust — so the instinct of the people who understand what we value sits beside everyone, and frees them to do their best work.
How we work with agents
From the pool, everyone draws the best of everyone. The real question is: how do I actually work with it?
The answer is to meet each person where they already work — one shared workforce, different doors in:
- Developers get the agentic workforce right inside their IDE.
- Executives simply talk to a personal assistant agent.
- Everyone else plug the same agents or RAG memory into their platform of choice.
The personal assistant is the part people feel first. An executive doesn’t open a task board — they talk to an agent that reads their tone, their sense of urgency, and what they actually mean. It quietly coordinates the rest of the agentic workforce to get the work done, then reports back the way that person likes to hear it.
And it runs wherever it needs to — on your own machine, in the cloud, or embedded inside a platform that lets external agents join. Same talent pool, many surfaces.
So the day looks like this: a goal lands. The personal assistant breaks it into tasks and hands each to the agents that fit. They do the work with the best of what we — and our agents — already know, then open it up for another human to review before it ships. Our rule when the output is bad: fix the prompt, not the code.
One shared workforce, many doors in — developers in VS Code, executives on mobile chat, everyone else on the platform they already use, all drawing from the same agents and shared memory.
And this was never just for engineers — the same idea fits legal, marketing, and HR, in the tools each team already uses.
How do we keep a human in the loop
An agentic workforce lives or dies on its constitution — a clear set of rules, best practices, and boundaries the agents must stay inside. Designing that, and deciding exactly where a human steps in, is the technical architect’s real job. The goal was never to hand everything to the agents. It’s to let them take the complex, repetitive, and resource-intensive work while people keep the judgment calls.
Code review is where this shows up most clearly. Every developer already has a set of agents that reason about clean code, clean architecture, and the rules written in our contributing.md. Here’s how a change actually moves:
- A product owner sets a goal. An agent turns it into tasks and assigns one to a human developer.
- That developer runs a small loop on their machine, always watching for three things: a new task, review comments on their work, or a request to review someone else’s. When one fires, their agents pick it up and carry it to done.
- New work doesn’t wait on the author — it’s taken by the agent and routed to another developer, whose agent performs the review. The change bounces through two or three rounds between different developers’ agents before a human ever looks.
- Then a human makes the call at the merge. About nine times out of ten, it’s already in good shape to accept.
- When it’s not — when the change is a mess — we don’t grind on the code. We discard the merge request and go back upstream to the specification, rewriting the requirements so the ambiguity that caused the mess can’t happen again.
That last move is the whole philosophy in one line: when the output is bad, fix the spec, not the code. Humans stay where their judgment matters — setting direction at the top, accepting the result at the end — and the agents do the miles in between.
Humans set direction at the top and accept at the end; agents do the miles in between. When a change is bad, we don't fix the code — we fix the spec.
We didn’t just make the agents smarter. We made the organization itself smarter — a little more every day.
Your company’s real bottleneck was never technology — you can always buy more tools. It was that your sharpest people could only be in one room at a time. That limit is now gone: their judgment can sit beside everyone, everywhere, at once.
So what do you build when your best judgment is no longer scarce? That’s where Part 2 begins — spec as source, the shared-memory backbone, and the cognitive testing that keeps it all honest.