AI agents

Building Smarter Agents with an Intermediate Protocol Layer

AI agents often fail because they're built like tangled 1970s BASIC scripts, sprawling and unmanageable.

3 min readInfoQ
Building Smarter Agents with an Intermediate Protocol Layer

There is a moment in every technology cycle when the gap between what we build and how we build it becomes too wide to ignore. Jake Mannix's presentation, "From Copy-Paste to Composition: Building Agents Like Real Software," points directly at that gap. His diagnosis is blunt: too many AI agents are being stitched together like 1970s BASIC programs, held together by global state, luck, and a prayer. That is not a sustainable architecture for anything, let alone for systems that handle data on behalf of an enterprise. The solution he offers is not a new model or a better prompt; it is an intermediate protocol layer that treats virtual tools as versioned, encapsulated components. That is a small change in wording, but a massive change in mindset.

We have written before about the perils of trusting AI outputs, whether it is the unease of Talking to My AI Clone Taught Me to Question the Tech or the practical need to Verify Your AI's Understanding: A Simple Check for Tax Season. Those concerns are real, but they are symptoms of a deeper issue: we are handing agents more responsibility without giving them the same discipline we expect from our software. Mannix's proposal flips that. By introducing interface mapping and dynamic schema projection, he is not just making agents safer; he is making them observable. You can test a versioned tool. You can roll it back. You can reason about its behavior under load. That is what engineering looks like, and it is what we should demand from every agent that touches production data. The runtime taint tracking he describes is not a nice-to-have; it is the difference between a system that quietly fails and one that actively prevents data exfiltration before it happens. That is not paranoia. That is accountability.

For engineering leaders, this should reframe how you evaluate agent frameworks. The question is no longer "Which model is smarter?" but "How do I compose, version, and secure the tools that use the model?" Mannix is not arguing for slower delivery; he is arguing for velocity that does not come with a hidden tax. The practical takeaway here is concrete: if you are building agents, you need an explicit protocol layer between the model and your internal systems. Without it, you are not building a product; you are building a lab experiment. And as the skills required for AI/ML roles continue to shift toward software engineering fundamentals, as Navigating AI/ML Job Requirements: A Shift in Expected Skills notes, this kind of architectural rigor will become the baseline expectation, not a differentiator.

The specific detail to watch is how taint tracking is implemented in practice. If it can be made cheap enough to run at runtime without degrading performance, it will become the default guardrail for every serious agent deployment. That is the line we are watching. Because once you can trace every piece of data that flows through an agent and kill a bad path before it leaves the boundary, you have moved past trust and into verification. That is the future worth building toward.

From InfoQ

Jake Mannix discusses moving AI agents past chaotic "1970s BASIC" architectures. He shares how implementing an intermediate protocol layer allows engineering leaders to build versioned, encapsulated "virtual tools." This design enables interface mapping, dynamic schema projection, and runtime taint tracking to proactively eliminate data exfiltration risks without slowing velocity.

Read the original at InfoQ