If you remember nothing else:
- Most companies build agents shaped like their org chart. One agent per system, each with its own chat box. That mirrors how the company is run, not how value is created.
- Data is never the point. The point is a story told or an action taken. A number from the warehouse only matters when it changes a decision or moves a customer.
- Skills compose. One fetches data, one reads a call transcript, one builds a branded deck, one sends it. The interesting work lives in the combination, not in any single skill.
- Design for a shared library of skills any agent can call, not a fleet of isolated department bots that will never talk to each other.
Walk into most companies a year into their AI push and you find the same thing. An ERP agent. A finance agent. An HR agent. A customer-service agent. Each one is competent. Each one has a chat box. None of them know the others exist.
This looks like progress, and it is, a little. But it is also a quiet mistake, because the shape is wrong. The company built its agents to match its org chart, and the org chart is how the company is governed, not how value actually gets made.
Data was never the point
Here is the thing that took me too long to say plainly. Nobody wants data. They want what the data lets them do.
A revenue number sitting in a warehouse is worth nothing on its own. It becomes worth something when it changes a decision, wins an argument, saves a customer, or triggers an action that would not have happened otherwise. The number is an ingredient. The meal is the story or the move.
An ERP agent that can answer “what were Apex’s orders last quarter” is a fine calculator. But the moment someone wants to use that number, they leave the agent. They copy it into an email. They paste it into a slide. They fold it into a conversation. The agent did the easy part and stopped exactly where the value started.
That handoff, from “here is the number” to “here is what we do with it,” is the whole game. And it almost never lives inside one system.
The shape that actually creates value
Let me make this concrete with a scenario I keep coming back to.
A salesperson has a call with a customer who is unhappy. The customer thinks quality has slipped and is hinting they might leave. The call gets recorded and transcribed, the way most calls are now. So far this is three disconnected facts in three disconnected places: a worry in a transcript, the truth in the warehouse, and a relationship at risk in someone’s head.
Now imagine the work as a chain of skills. One skill reads the transcript and pulls out the actual concerns, not the pleasantries. A second skill takes those concerns to the warehouse and gets the real numbers, the quality trend, the on-time delivery, the margin. A third skill notices the quality figure actually improved last quarter, which the customer does not know. A fourth skill builds a branded deck that answers each concern with the system-of-record truth. A fifth could schedule the follow-up.
The output is a deck, made for one customer, that quietly makes the case to keep them. That can be worth a seven-figure account. And not one of those skills is “the ERP agent.” The ERP is one ingredient among five.
You cannot build that by stacking department bots. You build it by composing skills.
Why this is just object-oriented thinking
If you have written software, this will feel familiar, because it is an old idea wearing new clothes.
Alan Kay’s whole point with object orientation, back in the 1970s, was small units that do one thing and talk to each other through clean interfaces. You do not build one giant program. You build composable pieces and assemble them. Skills are that idea, applied to what an AI agent can do. A skill is a unit of capability with a clear job and a clear interface, and the power is in how they combine.
The difference from old software is the part that matters. With traditional code you had to know the spec in advance. You had to decide, before you wrote a line, exactly what the program would be asked to do. The frustrating reality of business is that you usually do not know the spec, because you cannot predict what someone will ask for. That uncertainty is exactly what a capable model handles well. It can look at a messy request, figure out which skills it needs, and assemble them on the spot.
So you get the composability of good software without having to have predicted the request. That combination is new, and it is the thing the “one agent per system” crowd is leaving on the table.
What a skill library looks like
The unit to invest in is not an agent. It is a skill, and a place to keep them.
Picture a shared library. A data-fetch skill that knows your curated views. A transcript-reading skill. A deck-building skill that carries your brand. A skill that reaches your email. A skill that knows how to write to your project tracker. They live in one place, version-controlled, each owned and maintained. Any agent, for any person, can reach for any of them.
Now the marketing team’s branding skill is available to the sales workflow. The finance team’s metric definitions are available to the customer-service flow. A skill built once, by whoever needed it first, compounds across every function that comes after. That is the opposite of the siloed-bot world, where every team rebuilds the same capability behind its own wall.
And because a model can fan out parallel sub-agents, each in its own fresh context, a big library is not a burden. The agent does not load all hundred skills into one crowded window. It picks the few it needs and dispatches them. The library can grow without the system getting slower or dumber.
The interfaces this opens up
Once you think in composable skills instead of department bots, something else falls out: the chat box stops being the only way in or out.
A skill chain can run on a schedule and push a morning risk digest to an executive. It can run machine-to-machine and hand clean JSON to another system. It can render a deck, a document, a dashboard, or a plain answer, depending on what the moment needs. The same underlying capability, many surfaces.
The department-bot model cannot do this, because each bot is welded to its chat interface. The skill-library model treats chat as one consumer among several. That is a much bigger design space, and it is where the genuinely useful applications live, the proactive ones, the ones that act before you ask.
What to do differently on Monday
Stop scoping work as “let’s build the X agent.” Start scoping it as “what skills would this need, and which do we already have.” The first question builds silos. The second builds a library.
Resist the urge to mirror your org chart. Your departments are a governance structure. They are not a map of how value flows, and value almost always flows across them. The customer-save deck needed sales, data, and marketing skills in one chain. Real work is cross-functional, so the capabilities should be too.
Invest in the library and its plumbing. A shared, version-controlled home for skills, with owners and a change process. This is less exciting than a flashy demo bot, and it is the thing that pays off in year two when the tenth use case reuses the skill the first one built.
I have run my own company on this pattern for a while now, and the shift in mindset was the hard part, not the technology. Once you stop asking “what bot do we need” and start asking “what can these pieces do together,” the ceiling lifts. The ERP agent was never the goal. It was one gear. The machine is what you build around it.
