The Agent Integration Problem

I went to a recent FME Breakfast of Champions event in Calgary to see what Safe Software has been doing with MCP and AI inside the FME ecosystem. One demonstration in particular stuck with me, partly because of what it already did and partly because of the last mile it left open.

The workflow received an error from a failing FME Flow job, sent it to an agent for diagnosis, and emailed the diagnosis to a team inbox. The email included webhook-backed buttons that let the team confirm the suggestion as a known fix or reject it as the wrong answer. A confirmed fix could then go into a knowledge base, which meant the system was capable of learning something useful from the failure instead of letting the same error become fresh archaeology next month.

That is already a solid use of an agent. After the talk, though, I suggested taking it one step further.

If the diagnosis matches a known fix, why stop at the email? Give the agent a set of approved repair tools, let it connect to a persistent VM or local server, have it modify the .fmw workspace being uploaded to FME Flow, and run the file back through the pipeline. The presenter agreed that it would make for a pretty amazing end-to-end solution and said it was something they could consider moving forward.

That conversation put words to something I'd been circling for a while:

The whole thing about agentic solutions right now is finding a way to get it all connected.

The model isn't the bottleneck I keep seeing

There is still plenty of worthwhile work happening at the model layer. Models get faster, cheaper, and more capable. Teams will keep choosing providers, tuning behavior, and deciding what should run locally. I don't think that disappears.

But for people already employing AI, the more immediate challenge is usually everything around the model. Can the agent reach the application where the work starts? Can it find the internal data that explains what happened? Can it call the service that owns the next step? Can it make a change, observe the result, and decide whether the problem is actually resolved?

An agent sitting in a chat box can explain a system. An agent connected to the system can participate in it.

That changes how I think about AI integration. The model call is one component in a larger piece of systems engineering. The valuable part is the connective tissue between company data, applications, internal services, and the environment where the agent is allowed to work.

I've written before about wanting a [[building-myself-a-persistent-agent-on-paper-for-now|persistent agent]] rather than a session that disappears the moment the terminal closes. Persistence is part of this because useful agents need somewhere stable to run, but uptime alone isn't enough. A persistent agent with no access is just a very available spectator.

Connection does not mean dumping everything into a prompt

When I say an agent should be connected to all of a company's useful internal surfaces, I don't mean every table, document, and log line should be shoved into one heroic context window. That gets expensive, noisy, and dumb pretty quickly. I am already [[against-infinite-context|against treating infinite context as the answer]].

The agent needs the ability to reach the right information when the task calls for it. That might mean searchable documentation, a retrieval layer, a read-only database API, an MCP server, or a purpose-built tool with a narrow response. The difference matters. Access to a body of knowledge is an architectural capability; loading the entire body into every request is a context-management failure.

This is also why [[documentation-is-agent-infrastructure|documentation becomes agent infrastructure]]. Connecting an agent to ten systems does not help much if none of those systems can explain their contracts, ownership, failure modes, or operating rules. The agent needs both reach and legibility.

So my take is: an internal agent should be able to read broadly across the information required to understand the company and its systems. The implementation can respect data classifications, team boundaries, and genuinely sensitive domains, but the goal should be broad organizational visibility. Otherwise we keep building assistants that are clever inside a tiny room and blind everywhere else.

Write access is more situational. A support agent, a deployment agent, and a reporting agent should not inherit the same authority. The useful question isn't whether agents should ever write. It is which actions this agent needs, against which systems, under which conditions.

Put the agent inside a boundary

The stronger the connection, the more important the execution boundary becomes. If an agent can inspect files, run commands, reach internal APIs, and modify production-adjacent assets, I want a clear place where that activity lives.

Containers are the practical starting point I keep coming back to. Docker gives a process its own filesystem view, namespaces, resource controls, and network configuration. It is familiar, portable, and easy to reproduce. I have used this pattern in applications where a container spins up agents temporarily and gives them access to specific internal actions, even though I haven't yet hosted the persistent version of this system that I have in mind.

A container by itself is not the complete security model. Docker's own security guidance calls out the daemon, mounts, Linux capabilities, and kernel isolation as separate areas of risk. Its networking documentation also makes an easy-to-miss point: containers have outbound network access by default. If the agent should only reach three internal services, putting it in a container does not create that allowlist for free.

The sandbox has to be built around the job:

• Run the agent as an unprivileged user and remove capabilities it does not need.
• Mount only the files it needs, preferably read-only until a task requires a controlled write path.
• Give it explicit network routes instead of treating the entire internal network as one trusted blob.
• Inject scoped, short-lived credentials for the services involved in the task.
• Capture its tool calls, file changes, outputs, and failures so another system or person can inspect what happened.
• Tear down disposable environments when the task is complete, or make the state of a persistent environment deliberate and observable.

Vercel is a useful signal here because its agent tooling and sandbox product attack the two sides of the same problem. The AI SDK gives developers a structured way to build agents that use tools in loops, while Vercel Sandbox provides isolated microVM environments with their own filesystem and network for running agent-generated or otherwise untrusted code. I don't read that as one vendor having the final answer. I read it as evidence that the runtime around an agent is becoming a product category of its own.

Three controls define what the agent can actually do

The prompt tells the agent what it should do. The system around it determines what it can do.

For the kind of sandbox I am describing, three controls matter most:

Control	What it decides
Credentials	Which identities, roles, records, and operations the agent can authenticate against
Network boundaries	Which services and endpoints the sandbox can reach at all
Tools	Which actions the agent can understand and invoke

Credentials should be agent-specific. If an agent only needs to inspect an FME workspace and submit a candidate replacement, it should not borrow a developer's general-purpose account. Give it a role with exactly those operations, then make read and write access separate decisions where the underlying service allows it. Docker Compose and other runtimes can grant secrets to individual services, which is a much better shape than baking a shared API key into the image or spraying it across environment variables.

Network boundaries are the second half of that identity story. A scoped credential limits what the agent can do after it reaches a service. Network policy limits which services it can attempt to reach in the first place. I want both. If the job needs an internal knowledge API and an FME repair service, those can be reachable without also opening the finance database, the production control plane, and the public internet.

Tools are where the architecture becomes legible to the model. They can be MCP servers, SDK functions, command wrappers, or skills installed inside the sandbox. The format matters less than the contract: the tool needs a narrow purpose, a clear input schema, useful errors, and behavior the surrounding system can observe. MCP is valuable because it gives us a shared way to expose and discover capabilities, but a protocol does not decide which capabilities an agent deserves.

This is where I see a lot of room for companies to build around agents. Internal APIs can expose agent-specific operations instead of mirroring a sprawling human interface. Roles can be designed for automated workers. Tool repositories can package known actions. A second agent can review a proposed change, a deterministic check can validate it, and the system can log the whole chain before anything reaches a sensitive destination.

Close the loop, then verify it closed

The FME example is useful because the steps are easy to see.

The demonstrated system already handled:

1. Receive the failure.
2. Ask an agent to diagnose it.
3. Email the diagnosis to the team.
4. Let the team confirm or reject the suggested fix.
5. Save a confirmed fix to the knowledge base.

The extended version would continue:

6. Match a future failure to that known fix.
7. Select an approved repair tool.
8. Open the affected .fmw file inside the controlled environment.
9. Apply the repair.
10. Validate the changed workspace and send it back through the FME Flow process.
11. Record whether the repair actually worked.

That last step is important. Applying a known fix does not prove the system is healthy. The agent needs a result it can observe, whether that is a validation check, a successful run, or a human confirmation. Otherwise we have replaced an emailed suggestion with an automated guess and congratulated ourselves for moving faster.

Some repairs should still wait for approval. Others may be safe enough to run automatically because the change is reversible, the blast radius is small, and the validation is strong. I don't think there is one approval pattern for every agent. I do think every team should be able to explain why a particular action is automatic, gated, or forbidden.

This is systems engineering work

Calling this cloud engineering gets part of the way there because the runtime, networking, identity, and observability will often live in cloud infrastructure. But the broader shape is systems engineering. We are designing how components communicate, where authority begins and ends, how state moves, how failures are contained, and how the whole thing reports whether it succeeded.

That lens gives me a more useful way to evaluate an agent project. I would start with one real workflow and map it end to end:

• Where does the work begin?
• Which data lets someone understand it?
• Which systems own the possible actions?
• What is the smallest useful tool surface?
• Which credentials and network routes does that surface require?
• What result proves the action worked?
• What evidence do we retain when it does not?

Then I would put the agent inside that map. If it can only answer a question in the middle, the integration is incomplete. If it can touch every system with a shared admin key, the integration is careless. The interesting engineering lives between those two failures.

The trajectory I see is toward agents that can move through the full shape of a company's work. Getting there is going to require better internal APIs, better documentation, better identity design, better sandboxes, and tools built specifically for automated actors.

The challenge of the AI integration age is connecting agents to every useful surface. The companies that solve that well will be able to turn a smart suggestion into a finished, verified piece of work. Everyone else will keep forwarding the suggestion to an inbox.