Your Company Does Not Need 1,000 AI Agents
It needs one front door to 1,000 capabilities
Most companies are designing AI backward.
They start with a department. Build a sales agent. Add a support agent. Then a finance agent. Then every team buys two more. Six months later, the company has a pile of chatbots, automations, copilots, and internal demos that do not know one another exist.
It feels like progress because there is a lot of activity.
It is not a system.
A diagram of Stripe’s internal company agent, Kai, landed in front of me this week. I have not found a primary public source confirming every Kai-specific number in the diagram, so I am not going to repeat those as fact. But the architecture itself is worth studying because it flips the usual approach.
Instead of asking employees to choose from a catalog of agents, Kai appears to give them one place to start. The system reads the request, identifies the relevant skills, loads only the tools attached to those skills, does the work in a controlled environment, and returns a durable artifact.
That is the part that matters.
The future company agent may look less like an org chart full of digital employees and more like a capable chief of staff who knows which expertise to pull in, which systems it can touch, and what finished work should look like.
The agent is the front door.
A regional leader asks:
“Show me why implementation time increased in the Midwest, identify the accounts at risk, and draft the intervention plan.”
Today, that request usually becomes a relay race.
Someone pulls data from the CRM. Someone else asks implementation for a spreadsheet. Finance checks whether the accounts matter. Customer Success adds context. A leader turns the whole thing into a deck. By Friday, five people have produced six versions of the truth and scheduled a meeting to reconcile them.
A company agent should handle the coordination.
It should know that the request requires implementation analytics, account health, financial context, and an intervention-planning capability. It should load those skills, obtain the permitted data, run the analysis, and produce a report the team can inspect and continue editing.
The employee should not need to know which model, connector, database, or specialist workflow sits behind the request.
That is what a front door does. It receives intent and routes it into the building.
But a good front door does not make the building unnecessary.
How a thousand skills stay usable
The architecture depicted for Kai uses two passes.
In the first pass, the model sees lightweight descriptions of available skills. Enough to understand what each capability does, but not the complete instructions, examples, tools, and reference material behind it.
Once the relevant skills have been selected, the second pass loads the tools attached to them.
That sequence matters.
Most teams assume a more capable agent needs more context and more tools loaded at once. In practice, every extra option creates another decision. The model has to determine whether a tool is relevant, how it differs from similar tools, and whether invoking it will help. A giant global tool list turns capability into confusion.
LangChain describes the same principle in its public work on dynamically loaded agent skills (https://www.langchain.com/blog/langchain-skills): skills improve performance by loading specialized instructions only when the task calls for them. The model gets the expertise it needs without carrying the whole library through every conversation.
The simple version is:
1. Read the request.
2. Find the right capabilities.
3. Load their instructions and tools.
4. Execute the work.
5. Save the result.
The catalog can grow while the model’s active decision surface stays small.
That is a very different scaling model from adding another chatbot to Slack every time a team has a new use case.
A skill is more than a prompt
This is where I think most early agent programs will get stuck.
They will treat a skill as a clever prompt.
A real organizational skill needs more structure. It should contain the company’s specific way of doing the work, the knowledge required to do it well, the tools it may use, the permissions it inherits, the expected output, and the tests that determine whether it worked.
Take pricing approval.
The skill is not “analyze this discount.”
It needs the current pricing policy, approval thresholds, margin rules, contract constraints, customer context, escalation path, and output format. It may need access to CRM, billing, CPQ, and legal systems. And it should not inherit permission to change any of those systems merely because it can read them.
The skill becomes a governed capability package.
Publicly, Stripe already describes skills as structured instructions that give agents context to act. Its agent tooling documentation (https://docs.stripe.com/agents) also shows how financial actions can be exposed through agent frameworks. Kai’s depicted architecture brings those ideas inside the company: skills carry the judgment, while tools provide the hands.
That separation gives you scale without handing every request the keys to the entire building.
Keep the permanent context painfully small
Kai’s depicted architecture also includes a set of pinned skills that remain present across requests.
That makes sense, with one condition: the pinned layer has to stay small.
Company policy belongs there. Security boundaries belong there. The rules every employee request must follow belong there. A shared definition of the company, its customers, and its operating principles may belong there too.
The complete sales methodology does not.
Neither does the entire employee handbook, product catalog, approval matrix, or history of every decision the company has made.
Always-on context is expensive even when token cost keeps falling. The larger cost is attention. Every irrelevant instruction competes with the request in front of the model.
I learned this the hard way while building my own agent system. My first instinct was to make the agent smarter by telling it more up front. The result looked thorough and behaved inconsistently. The agent spent too much of its attention sorting instructions instead of solving the problem.
The better pattern is simple: pin the constitution, retrieve the expertise.
The artifact matters more than the answer
The other design choice I would copy is the filesystem.
That sounds painfully unsexy. Good.
Most AI work disappears into a transcript. The analysis is useful for ten minutes, then gets buried under the next thirty messages. Someone copies half of it into a document. Someone else takes a screenshot. The company has technically used AI, but the work has not become part of how the company operates.
Kai’s depicted architecture writes the output into files that can persist across turns. The user receives a report, dashboard, document, model, or other artifact that can be reopened and improved.
This changes the unit of value.
The agent is no longer rewarded for producing an impressive answer. It is responsible for advancing a real work product.
A forecast should remain a forecast model.
A launch plan should remain a launch plan.
A customer-risk review should remain connected to the accounts, assumptions, evidence, and decisions that created it.
Chat is the interaction layer. The artifact is the work.
Put generated work behind glass
The diagram also separates the agent from the environment where model-written code runs.
That is a load-bearing decision.
If the agent needs to execute Python, transform files, build a chart, or generate a document, that work should happen inside an isolated sandbox. The trusted process can inspect what the model proposes, run it under constrained permissions, read the result, and review the changes before accepting them.
Prompt-based guardrails are not enough. Telling an agent “do not access sensitive data” is weaker than building an execution environment where the agent cannot access it.
The permission model should follow the selected skill, the requesting employee, and the action being attempted. Read access to pipeline data does not imply write access to the CRM. Permission to draft a customer email does not imply permission to send it. The architecture has to enforce those distinctions below the prompt.
What Kai does not show
This is also where I would resist copying the diagram too literally.
It explains how one employee request moves through a company agent. It does not appear to explain the entire system the agent depends on.
A production company agent still needs:
- identity and role-based access;
- canonical company data and knowledge;
- durable memory across work and relationships;
- event-driven triggers for work nobody explicitly requests;
- evaluation, tracing, cost, and quality controls;
- human approvals tied to action risk;
- ownership and versioning for every skill;
- feedback loops that improve the system after outcomes arrive.
This is the boundary I use when thinking about the Revenue Nervous System.
The company agent sits at the interface. It interprets intent, coordinates capabilities, and performs work. The nervous system is broader. It supplies the data, memory, intelligence, orchestration, governance, and learning that allow the agent to act like it belongs to the company instead of merely having access to company tools.
The company agent is the executive function.
It is not the entire organism.
What I would build first
If I walked into a new organization tomorrow, I would not begin by building twenty departmental agents.
I would start with one company agent and three high-value skills.
The first skill would answer a recurring cross-functional question that currently takes several people and systems to resolve.
The second would produce a durable artifact that gets reviewed every week.
The third would execute a narrow workflow with a clear permission boundary and measurable outcome.
Then I would instrument the system:
- Did it select the right skill?
- Did it retrieve the right evidence?
- Did it use the correct tools?
- Did a human accept the artifact?
- Did the work change an outcome?
- What did the agent need that the company had never written down?
That last question is where the compounding starts.
Every failure reveals missing context, policy, data, or procedural knowledge. Fixing that gap makes the next run better. Over time, the company is not merely accumulating prompts. It is converting how the organization works into reusable, governed capabilities.
So do not start by asking how many agents your company needs.
Ask where employees should bring a request, how the system will find the right capability, what that capability is allowed to do, and where the finished work will live.
One front door.
A growing library of real skills behind it.
And a system that gets smarter every time someone walks through.