The Seams You Are Building

Every team can now build an agent. That is the promise. It is also the risk.

Sales can build one to research accounts, draft follow-ups and update the CRM. Support can build one to summarise tickets and suggest replies. Finance can build one to chase invoices. Operations can build one to watch queues and flag exceptions. Engineering can build one to triage incidents.

Most of these agents will make sense locally. That is what makes the problem harder. The danger is not that people build useless things. The danger is that useful local things create a broken whole.

Enterprise technology has a habit. A team finds a tool that solves its immediate problem. It adopts it quickly because waiting for a central answer is slow, expensive or impossible. The tool spreads. Another team does the same. Another does the same. For a while this looks like progress. Work moves faster. People are relieved. Leaders see energy and experimentation.

Then the joins appear.

One system has the customer name one way. Another has it another way. One workflow treats a case as resolved. Another still treats it as open. One team has permission to see the data but not to act on it. Another can act but cannot see the history. Reporting becomes argument. Handoffs become archaeology. The organisation discovers that the real cost was not the tool. The real cost was the space between tools.

Agents will repeat this pattern if creation outpaces ownership.

Agent sprawl is design debt at machine speed. It is what happens when every function builds its own little worker, its own memory, its own definition of context, its own permission model, its own escalation path and its own idea of done. It is not one bad bot. It is a hundred competent fragments all pulling on the same organisation without a shared architecture for how the work should join.

This is not an argument against agents. That would be lazy. Agents can remove drudge work, find patterns, shorten cycles, improve service and let people spend less time moving information between boxes. Many organisations should build them. Many teams should be allowed to experiment. Local initiative is not the enemy.

Ownerless joins are the enemy.

The question is not whether a team can build an agent. It is whether the organisation can absorb the seams that agent creates. What does it connect to? What does it change? What does it remember? What does it pass on? Who can stop it? Who owns the gap between what it does and what the next system or person expects?

A spreadsheet macro used by one person is one kind of risk. An agent that reads customer records, drafts advice, triggers workflows, updates systems and hands work to another agent is another. The second one is not only producing text. It is participating in operations. It has become part of how the organisation behaves.

That means it needs more than a prompt and a demo. It needs a place in the operating model.

Before celebrating the next agent, ask a dull question. Ask who owns the seam it adds. If nobody can answer, you are not building an automated organisation. You are building executable fragmentation.

The enterprise has already run this experiment.

It was called SaaS sprawl. Before that it had other names. Shadow IT. End-user computing. Rogue databases. Departmental tools. Local automation. Every generation gets its own version of the same story: the centre is too slow, the edge has a problem, the market offers a quick answer, and the quick answer becomes part of the estate before anybody has decided how it should be owned.

SaaS sprawl was not caused by stupidity. It was caused by rational behaviour inside a badly joined system. People needed to get work done. Procurement was slow. IT queues were full. Enterprise platforms did not fit the local job. A team bought a tool on a card, connected it to a few systems, invited colleagues and moved on.

For a while, it worked.

Then came the inventory problem. Which apps do we use? Who approved them? Which ones hold customer data? Which ones have admin access? Which ones were connected through OAuth grants nobody remembers? Which ones still contain data from people who left? Which vendors were quietly renewed because nobody wanted to be the person who turned off a workflow they did not understand?

Then came the data problem. The same customer existed in several places. The same employee existed in several places. The same contract, ticket, lead, invoice or policy had multiple versions. None of this looked dramatic in isolation. It became expensive because it happened everywhere.

Then came the access problem. People moved roles but kept rights. Contractors left but integrations stayed alive. Service accounts accumulated power. APIs were opened for one purpose and then reused for another. Security teams were asked to protect an estate they could not fully see.

Then came the human problem. People became the glue. They copied data from one place to another. They checked whether two systems agreed. They sent messages asking which version was true. They built spreadsheets to reconcile what the organisation should have reconciled by design.

SaaS sprawl was bad enough when the tools mostly waited for people to use them. Agents do not wait in the same way. They can call tools. They can take instructions and run across a chain of steps. They can retrieve data, summarise it, transform it, route it, trigger actions and pass work onwards. They can do useful work while also creating new uncertainty about who acted, under what authority, using which context and with what consequences.

That is the difference. A forgotten SaaS app can leak data, duplicate work and confuse teams. A forgotten agent can do those things while acting on the world.

The SaaS lesson is not that every local tool should have been banned. The lesson is that adoption without ownership creates a bill. You can delay the bill. You cannot cancel it.

Agents make the bill arrive faster. The cost is not only licensing or compute. It is integration, identity, context, monitoring, exception handling, audit, customer repair and organisational trust. It is the time spent proving what happened after nobody can remember why a particular agent had permission to do a particular thing.

There will be teams that say, “Let us ship it now and fix the architecture later.” Sometimes that is the right call. A low-risk internal assistant can be trialled quickly. A one-off tool can be useful. Not every experiment needs a ceremony. But “later” has to be real. If later means after the agent has become operational, connected, relied on and politically hard to remove, then later means never.

SaaS sprawl was the rehearsal. Agents are the live performance with moving parts.

If “fix it later” was expensive for software that mostly stored work, it will be worse for systems that do work.

A useful agent can still be a bad system.

This is the mistake many organisations are about to make. They will test an agent inside the boundary of a task. Can it answer the question? Can it draft the email? Can it update the field? Can it classify the ticket? Can it summarise the meeting? If the answer is yes, they will call it successful.

That is not enough.

Local task performance is not enterprise performance. A brilliant local assistant can still create global confusion. It can optimise one step while damaging the flow around it. It can make one team faster and another team slower. It can reduce visible work for a manager while increasing invisible repair work for everyone downstream.

The agent is not the architecture. The seam is the architecture.

The seam is where the agent meets another system, another team, another policy, another customer, another agent or another version of the truth. It is where local action becomes organisational consequence. It is where the question changes from “did the model produce a good answer?” to “did the system do the right thing in context?”

A support agent can summarise a complaint well and still fail if the billing system does not receive the right status. A sales agent can generate a good proposal and still fail if legal sees a different customer history. An onboarding agent can send correct instructions and still fail if access is not provisioned in time. A finance agent can chase a payment and still fail if the customer is in an unresolved service dispute.

None of these failures require the agent to be stupid. That is why they will be common.

Organisations are full of work that only functions because people carry context across weak joins. Someone remembers that this customer has an exception. Someone knows that this field is unreliable. Someone spots that the workflow says green but the real situation is red. Someone understands that a policy answer is technically correct and operationally foolish.

Agents will expose how much of the organisation depends on that informal carrying of context. Then, if designed badly, they will add more of it.

This is why agent design cannot stop at prompt design. A prompt can tell an agent how to behave in the narrow moment. Architecture decides what it can know, what it can touch, where it records action, how it hands off work, when it must stop, and who is accountable when its local success becomes a system failure.

The demo is usually the cleanest version of the future. It has tidy data, a clear task, a happy path and a human who knows what to look for. Real operations are not like that. They contain partial information, contradictory records, policy exceptions, impatient customers, handoffs, outages, incentives, fatigue and pressure.

An agent that only works in the demo is not ready for the seam.

The answer is not to wait until everything is perfect. Nothing in a real organisation is perfect. The answer is to know what kind of imperfection you are accepting. Is the agent advisory or can it act? Is it touching internal data or customer outcomes? Is the work reversible? Is there a clear owner? Can the organisation see what happened? Can a person intervene with authority? Can the agent be changed or stopped without a treasure hunt?

Those are architectural questions. They are not innovation blockers. They are how innovation survives contact with the organisation.

Agents need a place in the operating model, not just a prompt and a demo. If you do not design the seam, the seam will design the failure.

Most enterprise failures do not begin with a dramatic mistake. They begin with a gap everyone assumes someone else owns.

A join is the place where work crosses a boundary. Team to team. System to system. Agent to agent. Policy to action. Customer to organisation. It can be technical, operational or human. Often it is all three.

The join is where the CRM update becomes a fulfilment task. Where a support promise becomes a billing adjustment. Where a risk policy becomes a product constraint. Where a customer message becomes an internal case. Where one agent’s output becomes another agent’s input.

When a join is owned, someone has designed what should pass across it. They know what information matters, what authority is required, what exceptions look like, what evidence is kept and what happens when the handoff fails. It does not have to be heavy. It does have to be real.

When a join is ownerless, everyone can plausibly claim they did their job.

Sales captured the deal. Legal approved the clause. Finance set up the account. Support answered the question. The agent followed its instructions. The workflow completed. The dashboard stayed green. The customer still ended up in a mess.

This is why ownerless joins are so dangerous. They produce failures without villains. Neither agent has to be wrong for the outcome to be wrong. Neither team has to be negligent for the customer to experience contradiction. Each part can be defensible while the whole is indefensible.

Agents will multiply these joins. Some will be obvious: an agent reads from one system and writes to another. Some will be hidden: an agent summarises context in a way that changes how the next person understands the case. Some will be political: one function’s agent starts making decisions another function used to own. Some will be temporal: an agent remembers something that should have expired, or forgets something the next step depends on.

The customer experiences the seam, not the org chart.

They do not care that the refund agent sits in finance while the complaint agent sits in support. They do not care that one system says “case closed” and another says “awaiting approval”. They do not care that your employee could not see the note because the permission model was copied from a previous workflow. They experience delay, repetition, contradiction, unfairness, opacity and dead ends.

Inside the organisation, the same pattern hits colleagues. A frontline worker is told to trust the agent but still has to check three systems. A manager receives two summaries that do not match. An IT team finds an integration nobody documented. A risk team asks for evidence and gets screenshots, guesses and Slack messages. Nobody meant to build a bad system. They just failed to assign the join.

Ownership does not mean one person manually approves everything. That is bureaucracy pretending to be control. Ownership means there is a named accountable party for the behaviour of the seam. It means someone can answer: what crosses this boundary, under whose authority, with what evidence, and what happens when it breaks?

This is the governance that matters. Not a grand policy document nobody reads. Not a committee that meets after the architecture has already hardened. Governance at the join is practical. It is close to the work. It is scaled to the risk. It gives teams freedom to build while refusing to let them export the costs to customers, colleagues and audit trails.

Ownerless joins become ownerless failures. In the age of agents, those failures will move faster, look cleaner in dashboards and be harder to unwind after the fact.

When the architecture is weak, the user becomes the middleware.

This is the oldest trick in enterprise technology. A system is described as automated, but a person is quietly placed between its broken pieces. They read the output, check another system, correct the mismatch, explain the exception, copy the data, chase the approval and apologise when the customer notices.

The work did not disappear. It moved.

Agents can make this worse because they make the movement less visible. A leader sees an agent answering tickets and assumes workload has fallen. The frontline team sees a new queue of things to verify because the answers are plausible but not reliable enough. A product team sees an onboarding agent complete tasks. A customer success team sees customers asking why the instructions do not match their account. A finance team sees automated chasing. Support sees angry customers who were chased while a dispute was still open.

“One more assistant” can become one more thing to supervise.

That supervision is work. It takes attention. It creates anxiety. It interrupts judgement. It forces people to hold the system in their heads because the system cannot hold itself together. The person is no longer only doing their job. They are managing the agent that was supposed to help them do the job.

There is a particular cruelty in calling this empowerment. It is not empowering to give someone a tool that increases their responsibility without increasing their authority. It is not empowering to ask them to approve outputs they cannot inspect, override decisions they cannot trace, or repair customer journeys they did not design.

The human complexity burden shows up in ordinary places.

In support, it is the agent that drafts a reply using a policy article that is technically current but ignores the customer’s open complaint. The agent saves a minute. The employee spends five minutes checking the account, softening the tone and preventing a second problem.

In HR, it is the policy agent that answers an employee question correctly in general and wrongly in context. The employee acts on it. A human then has to explain the exception and rebuild trust.

In incident management, it is the triage agent that summarises logs, opens tasks and tags owners, while another agent updates status pages using a different interpretation of the same event. The incident commander becomes the integration layer between two partial realities.

Customers carry the burden too. They repeat information because one agent did not pass it on. They receive contradictory messages because two workflows used different definitions of status. They wait because an exception fell between automated queues. They lose trust because the organisation sounds confident and behaves incoherently.

Automation that pushes coordination onto people is not progress. It is a transfer of burden.

This matters because the burden is easy to hide. Dashboards count agent completions. They do not always count the checking, hesitation, context gathering, emotional labour and repair that surround them. A task can look automated while the organisation has simply moved the hard part into someone’s attention.

The right test is not “did the agent reduce a visible step?” The right test is “what new work did it create, and who now carries it?” If the answer is customers, frontline colleagues, managers or risk teams, the system is not finished.

Humans should remain in the system where judgement matters. They should make calls that require empathy, discretion, trade-offs and accountability. They should not be used as wetware connectors between badly designed agents.

If the user has to reconcile your agents, the design has failed.

An agent becomes dangerous or useful at the same point: when it can touch something.

Until then, it is mostly a talker. It may produce bad advice, confuse a person or waste time, and those risks matter. But the nature of the problem changes when the agent can read records, send messages, open tickets, change fields, trigger workflows, approve requests, call APIs or spend money.

At that point the question is not only what the agent can say. It is what the agent can touch.

Identity is the hard edge of agent architecture. Every acting agent needs to exist under an access model the organisation can defend. Not vibes. Not “it uses my login”. Not a shared service account created in a hurry and then forgotten. A real model.

That means a sponsored identity. A named owner. A defined purpose. A permission boundary. Least privilege. Logging. Review. Revocation. A lifecycle. A way to be stopped.

The words matter because the risk lives in the nouns: service accounts, OAuth grants, API keys, delegated permissions, admin roles, tokens, secrets, connectors. These are not implementation details to tidy up later. They are how the agent enters the organisation.

“It uses my access” is not an access model. It is a confession.

If an agent acts through a human’s credentials, the organisation loses clarity. Did the person do it? Did the agent do it? Was the action inside the person’s role, or did the agent inherit more power than the task required? What happens when the person changes role? What happens when they leave? Who reviews the permission? Who sees the pattern of use?

If an agent acts through a shared credential, the problem changes shape but does not go away. Shared power is easy to create and hard to govern. It blurs accountability. It survives beyond the original purpose. It gets copied because it works. It becomes one more quiet dependency in the estate.

Agents need identities appropriate to their role. Some should only read. Some should suggest but not write. Some should write to low-risk systems under tight constraints. Some should trigger consequential actions only with explicit approval. Some should never exist because the work is too sensitive, too ambiguous or too poorly understood.

This is not about being timid. It is about matching authority to purpose.

The permission boundary should be boringly specific. What can the agent read? What can it create? What can it update? What can it delete? What can it send outside the organisation? What workflows can it trigger? Which environments can it touch? Which customers, records or cases are out of scope? What rate limits, spending limits or approval limits apply?

Then the lifecycle has to be real. Who approved the agent? When is access reviewed? What changes require reassessment? How is the agent monitored? How is it disabled? What happens to its memory, logs and credentials when it is retired?

This is governance without bureaucracy. It does not require every low-risk experiment to crawl through months of theatre. It does require that agents with access have accountable sponsors and boundaries before they become load-bearing.

Every agent needs a sponsor, a permission boundary and a way to be stopped. Without those, you have not created autonomy. You have created unattended authority.

Agents do not run on intelligence alone. They run on context.

This is where much of the public language around agents gets sloppy. People talk as if a better model will simply know what matters. It will not. It will know what it is given, what it can retrieve, what it has retained and what the system tells it to treat as true. If those things are messy, stale, contradictory or unauthorised, the agent will carry that mess into action.

Context is not a magic mist that can be sprayed across the organisation. It has ownership, lineage, expiry and permission.

Who owns the customer profile the agent uses? Which system is the source of truth for account status? Which policy version is current? Which notes are allowed to influence decisions? What context can be shared between agents? What must be forgotten? What must never be placed in memory? What happens when two sources disagree?

These are not abstract data questions. They become customer experiences.

If every agent carries a different version of the customer, the customer will meet all of them. One agent remembers the complaint. Another does not. One agent sees the renewal risk. Another only sees the invoice. One agent treats a person as a prospect. Another treats them as an existing customer. The organisation then speaks with several mouths and asks the customer to make sense of it.

Memory makes the problem sharper. An agent with memory can become more useful because it does not start from zero each time. It can remember preferences, prior actions and repeated patterns. It can also remember the wrong thing, retain something beyond its proper life, apply context outside the situation where it was valid, or expose information to a later workflow that should not have received it.

Memory needs policy. Not a paragraph in a risk document. Product-level rules. What is stored? Where? For how long? Under whose consent or lawful basis? Who can inspect it? Who can correct it? When is it deleted? How is it separated between customers, teams and purposes?

Retrieval needs the same discipline. If an agent searches documents, which documents? Are drafts included? Are obsolete policies included? Are customer notes mixed with internal speculation? Are permissions enforced at retrieval time, or did someone dump a whole knowledge base into reach because it was easier?

Context handoff is just as important as context access. When one agent passes work to another, what crosses the boundary? A summary? A full transcript? A structured state? A confidence score? A list of unresolved questions? A warning that the case contains an exception? If the handoff loses the crucial detail, the next agent may behave perfectly according to bad context.

The organisation also needs a way to handle conflict. Two systems disagree. Two agents infer different priorities. A policy says one thing and a customer promise says another. The answer cannot be to let whichever agent acts last define reality. There must be rules for conflict, escalation and correction.

Better models will help. Larger context windows will help. Better retrieval will help. None of them remove the need to decide what the organisation means by truth in a given workflow.

Shared context is designed. It is not wished into existence by a larger model.

You cannot govern what you cannot reconstruct.

This is where the romance of autonomy meets the dull necessity of evidence. An agent did something. A customer was affected. A cost was incurred. A record changed. A message was sent. A decision was suggested, accepted, overridden or ignored. Now the organisation needs to know what happened.

If the answer is “we think the agent probably...”, the system is not trustworthy. It may be useful. It may be impressive. It may even be right most of the time. But it is not governable.

Trust is not a feeling about the demo. It is evidence after the event.

For agents, that evidence has several parts. Which model was used? Which prompt or instruction version? Which tools were available? Which tool calls were made? Which data was retrieved? Which memory was read or written? Which policy or guardrail fired? What did the agent output? What did a human approve, edit or reject? What changed in downstream systems? What did it cost? How long did it take? What customer effect followed?

This does not mean every trace should be sprayed across the company. Logs can themselves become sensitive data. Observability needs access control, retention rules and care. But the organisation must be able to reconstruct consequential work. Otherwise risk, audit, engineering and operations are left reading tea leaves after the damage is done.

A black-box agent is not autonomous. It is unaccountable.

Good observability is not only for blame. It is how systems improve. Without traces, you cannot see where an agent is hallucinating, looping, overusing tools, ignoring instructions, escalating too late, escalating too often, spending too much, slowing down a workflow or creating work for people downstream.

Evaluation belongs here as well. Agents need test cases that resemble real operations, not only happy-path prompts. They need examples of edge cases, policy conflicts, missing data, angry customers, ambiguous requests and unsafe actions. They need to be tested before release and watched after release because behaviour changes when tools, prompts, models, data and users change.

Cost and latency are not side issues. A slow agent can break a service promise. An expensive agent can make an apparently efficient workflow uneconomic. A cheap but unreliable agent can create hidden labour elsewhere. Observability should show the full operating shape, not just whether the model answered.

There also needs to be rollback. If a prompt change makes behaviour worse, can it be reversed? If a tool integration misfires, can it be disabled? If a model update changes output quality, can the system fall back? If an agent starts generating bad downstream actions, who gets alerted and who has the authority to stop it?

This is the operational version of trust. Not trust as enthusiasm. Trust as bounded, visible, recoverable behaviour.

If you cannot trace the seam, you do not own it.

Putting a human in the loop does not make a weak system safe.

It can. But only if the human has what a control needs: authority, time, context, evidence and a clear route to act. Without those, “human in the loop” is decorative. It is a phrase placed over a system to make everyone feel better while the real design remains unchanged.

A human without authority, context or time is not a control.

Consider the employee asked to approve agent recommendations at speed. The queue is long. The output is fluent. The source material is hidden. The policy is ambiguous. The system records their click as approval. If something goes wrong, the organisation says a human was involved. That is not oversight. That is liability transfer.

Or consider the manager who receives agent summaries from several teams. The summaries do not show confidence, missing information or conflicts. The manager is expected to spot what the system did not make visible. Again, the human is being used as a moral decoration for an architecture that does not support judgement.

Real oversight starts earlier. It asks which actions require human judgement and why. It distinguishes between review, approval, exception handling, escalation and accountability. It gives people the ability to inspect evidence, ask for more context, override the agent, correct the record, pause the workflow and improve the system.

It also respects attention. If a human is asked to review too much, they will review badly. If every low-risk action asks for approval, people become numb. If only catastrophic decisions ask for approval, people may lack practice and context. Oversight design is a workload design problem as much as a control problem.

The right level of human involvement depends on consequence. Drafting a low-risk internal summary is not the same as denying a customer request, changing a payment term, sending a legal notice or terminating access. Some agent actions should be automatic. Some should be suggested only. Some should require approval. Some should be forbidden. The organisation has to make those distinctions before the agent makes them accidentally.

Human escalation also needs a path. When the agent is uncertain, who receives the case? With what context? In what time frame? With what authority? If the answer is “it goes to a shared inbox”, that may be a queue, not a control. Exceptions are where systems reveal whether they were designed or merely launched.

There is another mistake: using humans to patch bad architecture permanently. A temporary human check during a pilot can be sensible. A permanent human reconciliation layer between agents is a sign that the system has exported its complexity. The work should be learned from, designed out where possible and reserved for judgement where necessary.

This is not anti-human. It is the opposite. It protects human judgement from being buried under machine mess. People should handle ambiguity, empathy, trade-offs and accountability. They should not spend their days proving that one agent’s version of reality matches another’s.

Do not use humans as moral decoration for systems they cannot understand or stop.

The alternative to agent sprawl is not fewer agents. It is owned joins.

Build agents where they help. Build them for the repetitive work people hate. Build them for search, summarisation, drafting, triage, monitoring, routing and recovery. Build them where speed matters and where better access to context can improve the work. Let teams experiment. Let them solve real problems. Do not smother useful invention under a fake demand for perfect central control.

But do not confuse freedom to build with freedom to leave the seam to someone else.

Before you ship the next agent, name the join it creates and the person who owns it. Then ask the plain questions.

• Who is the accountable sponsor?
• What job is the agent meant to do?
• What systems, teams, customers or agents does it touch?
• What identity does it use?
• What can it read, write, change, send, delete or trigger?
• What must it never do?
• What context does it need?
• What context must it pass on?
• What does it remember, and for how long?
• What happens when sources disagree?
• When must it stop and ask for help?
• Who receives the escalation?
• What evidence is logged?
• How can the organisation reconstruct a decision?
• What customer burden does it remove?
• What customer burden might it create?
• How is it monitored, changed and retired?

These questions are not paperwork. They are the design.

The answer does not have to be the same for every agent. A small internal helper does not need the same treatment as an agent that changes customer records. A read-only assistant does not need the same controls as an agent that sends external messages. A trial used by five people does not need the same machinery as an operational agent used across a business line.

Governance without bureaucracy means proportionality. Lightweight where risk is low. Strict where action is consequential. Clear everywhere.

The organisations that get this right will not be the ones that slow everything down. They will be the ones that make the safe path the easy path. They will provide approved identity patterns, shared context services, tracing by default, evaluation harnesses, escalation routes and retirement processes. They will give teams building blocks for owned seams instead of asking every team to invent access, memory and audit from scratch.

They will also keep asking the human question. Who is carrying the complexity? If the answer is the customer repeating themselves, the worker checking every output, the manager reconciling dashboards, the IT team hunting orphaned credentials or the risk team reconstructing decisions from fragments, the architecture is not done.

Agent sprawl will not announce itself as sprawl. It will arrive as helpfulness. A useful assistant here. A clever workflow there. A pilot that becomes permanent. A local success that becomes a dependency. By the time the organisation notices the pattern, the agents will be woven into work, and unwinding them will mean touching customers, teams, systems and politics.

So notice earlier.

The next agent you build is also a seam you build. It has an owner or it does not. It has a permission boundary or it borrows authority. It has shared context or it invents its own. It has evidence or it leaves a fog. It reduces human burden or it hides it.

Build agents where they help. Build seams where they matter.

The organisations that win will not be the ones with the most agents. They will be the ones whose agents can work without making everyone else carry the joins.

Before you ship the next agent, name the seam it creates. Then name the person who owns it.

If you cannot answer who owns the identity, context, escalation, evidence and customer burden, the agent is not ready to become part of the operating model.