A person, and a dozen open windows.
Picture the work as it is done today. A senior analyst sits in front of a dozen systems.
Closing one piece of work means toggling between a line-of-business platform, two spreadsheets, a dashboard, a reporting tool, an inbox and a chat window. An hour disappears into clicks.
The point is never to remove the person from the process. It is to move them from repetitive tool operation to goal-setting, judgement and review. To see how, start with what any piece of work actually runs on.
A person gets work done with five things.
Skills are scarce
Skills are a person’s most valuable asset at work. They are also the hardest thing for the organisation to capture and keep.
- Each person carries a slice of the team’s skills; no single person holds them all.
- When someone leaves, their skills walk out of the door.
- Documentation alone cannot hold them — written procedures go out of date quickly, and skills themselves shift every time they are practised.
Skills are fluid. The more we use them, in more situations, the more they change shape. We pick the wrong tool, run a step out of order, miss a check — and learn from it.
Mistakes are not the opposite of skill; they are how skill is shaped.
The organisation’s quiet wish is for everyone to have access to everyone else’s skills. Today, that is not possible.
Software still builds the tools. It just builds them for agents now.
Software has always been about building the best tools for the people doing the work. That is not ending. What is changing is who we are building these tools for.
We are now building tools for agents — and we are building agents for people. The user’s job becomes setting the goal and reviewing the work; the agent’s job is to operate the tools.
An agent has an equivalent operating stack, rebuilt in software. It is not a like-for-like replacement, but the categories line up.
Agents can reason, plan and use tools — abilities of the same category as ours. They do not match people on setting the goal in the first place, on original ideas, or on judgement at the edge of a hard decision. So the division of labour is clear: humans set the goals, humans stay in the loop, humans review.
Seen this way, the change is smaller than it first sounds. We already have the tools. People already know how to use them. We do not need to rewrite the software or redesign the processes. We need to expose what we already have to agents running in a quality harness.
The strategy is mostly subtraction, not addition: same systems, same processes, less manual tool handling, one harness around the work.
A model can think and talk. It cannot get work done.
On its own, a model has no memory between conversations, no tools, no audit trail, no safety, no place to learn. The harness is what turns a model into an agent that can run inside a business.
An agent is a loop around a model and a set of tools. A goal goes in. The model produces a plan. It requests tools. The harness runs them. The result returns. This runs until the goal is met. The harness is the software that:
- Runs the agent loop and holds its memory between sessions.
- Dispatches tools on the agent’s behalf — and decides what the agent is allowed to do.
- Captures skills from real sessions and makes them reusable.
- Records and audits every step.
- Keeps each user’s session isolated from every other.
What the harness builds around it
Two kinds of harness
A developer on a laptop running a coding agent is using a harness. It works for one person, one machine, one day’s work. It cannot run a business. An enterprise harness is a different thing entirely: it runs on the backend, as a service.
A coding agent on a laptop
- One user, one machine
- Configured per device
- Nothing shared, nothing kept
Agent Circuits
- Many users at once, each isolated
- Sessions stored centrally — searchable, replayable
- Skills captured once, shared to permitted others
- Tools and permissions managed centrally
- Sized to the firm, not to a laptop
Agents on a laptop are a curiosity; agents on a proper backend harness are how a firm gets work done.
Here is why that matters. A person’s skills live in one head, walk out of the door at five o’clock, and never compound. A skill in a harness is the opposite. It is captured business workflow logic — how this team closes a piece of work, how we compile the weekly report, how we reconcile a mismatch — learnt as a human steers the agent through real work.
Once captured, a skill is reusable. The next time the same situation appears — for another user, on another team, within the permission scope the harness enforces — it is already there. Skills stop being scarce.
One agent uses tools. The larger shift is an agent that hands work to other agents.
Orchestration is giving a goal to an agent that achieves it by delegating to others. The orchestrator breaks the goal into sub-problems, hands each to the agent best suited to it, then gathers the results back — analysing them, verifying them, critiquing them, and compiling them into the answer.
Imagine handing an agent a drawing of a house and asking it to build it. It does not try to do everything itself. It brings in a group of specialists — a heating engineer, an electrician, a joiner, a plasterer, a painter, a plumber — and gives each the part of the job that is theirs. Each has its own tools. And each can bring in its own sub-specialists: the electrician takes on a junior electrician; the joiner calls in a structural engineer. The work fans out to whatever depth the job needs.
Tools are not sub-agents. A tool is something an agent operates. A sub-agent is something an agent delegates to.
Without orchestration you can still build the house — you would just be holding it all together yourself. Brief the electrician, wait, take the result, brief the plumber, reconcile the two, chase the joiner. Either way, you become the orchestrator, doing the project management by hand. That is exactly what you are left with when agents cannot delegate: a drawer full of them, each solving one small problem, and a person in the middle wiring them together.
Delegation is not only agent-to-agent. A question that needs answering is itself a task — and sometimes the right person is the one to answer it. An agent that cannot find the data it needs contacts the person who would know, rather than failing quietly. That person can steer it back onto the path, or say this is not possible right now — and the agent returns to its orchestrator with a clear reason why.
This completes a picture the rest of the story only half-told. People are not only above the agents, approving their actions. They are also participants the work can be routed to — addressable, like any other agent in the graph.
The difference between an agent adopted and one quietly abandoned is rarely the model.
A good agent is more than a model with tools wired up. It is something a user wants to work with. Agent Experience — AX — is the discipline of building agents that feel good to use.
- Steerable, not rigid. It follows intent without making the user spell out every step, and adjusts when redirected.
- Retains preferences. It remembers how this user works — naming conventions, default projects, common accounts — across sessions, not just inside one.
- Aware of your context. It knows the session you are in and the views you have open, so it works from what is in front of you rather than a blank slate.
- Personality. Tone, pace and phrasing matter.
- Fast, or felt to be fast. Streaming responses, visible reasoning and progress signals turn a forty-second wait into a forty-second collaboration.
- Recoverable. When something goes wrong, there is always a continuation — undo, retry, back up, take a different approach.
A drab agent gets the same answer as a sharp one and is used half as often.
These traits are not features of a model. They are choices the harness makes — built in once, so every agent inside it inherits them. Building agents this way is a new engineering discipline. Managing context, designing skill-capture loops, shaping personality, picking where to surface progress: this is agent-craft, and it has to be learnt. The team that practises it accumulates a capability no off-the-shelf product can match.
An inflection arrived, from late 2025 into early 2026.
Frontier models became good enough at long-horizon agentic work — running for hours, with limited human intervention, at a meaningful success rate — that the technology is finally ready for prime time inside an enterprise. Earlier waves were demos; this one is operational.
- Tool use is finally reliable enough for governed workflows. Models reason against the same controlled interfaces our software already exposes, call them with structured arguments, and use the result — no need to build new applications just to let the model act.
- Agents clear a real economic-value bar. This is no longer a future promise; the savings and the skill capture are happening in production.
- Captured skills compound. The firm that starts capturing them today builds a library a competitor cannot buy off the shelf next year.
The cost of waiting is not just a delayed efficiency gain. It is a delayed learning curve. Skills keep leaking through role moves, holidays and undocumented workarounds. Teams adopt local AI tools anyway, but without shared governance, shared memory or shared skills. Peers who start earlier begin accumulating their own workflow libraries while you are still evaluating.
We do not need to be reckless first movers. We do need to avoid becoming late learners.
An enterprise harness carries obligations a local one never does.
Five risks. Five non-negotiables.
Human in the loop, by default
Agents propose; humans approve, until trust is earned per workflow. Per-tool approval prompts, wake notifications when an agent pauses on an action, and explicit rules naming what it may do without asking.
A kill switch
Any agent, any session, any tool — stoppable centrally, in seconds.
Your regulators, your data boundaries
The harness does not replace your compliance function or your internal controls. It gives them something concrete to inspect.
- Prompts, tool calls, approvals, outputs and final answers are tied to a user, a session, a timestamp and an agent.
- Each model provider is approved for a defined class of data. You know which information may be sent to which provider, where it is processed, and under which terms.
- Your data must not train an external model unless that is explicitly approved.
- Secrets and credentials sit in your own vaults, accessed by the harness and tool layer — never pasted into prompts.
- Any action that writes to a real system needs an explicit permission and a human approval, until the specific workflow has earned the right to run on its own.
If the house showed how the work fans out, think of an orchestra to see who stays in charge. Every section gets the score. The orchestra is not replaced.
The conductor stays human.
Fewer moving parts than a typical transformation programme.
Each phase has a quick win, a measured outcome and a guardrail. The next phase only starts when the previous one passes review.
Two trajectories compound. The more it is used, the more useful it gets — every session can add to the skills repository. And models keep getting better, fast, so agents reason better and learn skills faster. The more the firm uses this, and the more kinds of people use it in their own ways, the wider the gap with any firm starting later.
Anyone can give their staff a chatbot. The compounding asset is what your people teach your agents, and what the agents pass on to each other.
- A new joiner arrives on day one with the team’s accumulated skills already wired in.
- Skills do not walk out of the door when someone leaves.
- The organisation learns.
Bounded. Measurable. Reversible.
To cut the rumours before they form.
- We are not replacing your people.
- We are not handing agents autonomous, unsupervised control of high-consequence actions. As trust in agent-run workflows grows, more may become possible later; it is deliberately outside the early phases.
- We are not building “another chatbot”.
- We are not binding the firm to a single model vendor.
- We are not giving agents production write-access without per-agent permission scopes and human approval.
- We are not letting agents delegate to one another without bounds — every orchestration is depth-limited, fully recorded, and has one named human accountable for it.