Beyond the AI Wrapper: Designing the System Around the Agent

A useful agent needs more than a model and an API endpoint. It needs an environment in which evidence is accessible, actions have clear meaning, and failure produces something the system can work with. Weakness in any of those interfaces can look like a reasoning failure.

At Tokyo AI’s Beyond the Wrapper on 15 April 2026, Adam Gibson, Leonard Lin, and Jason Mooberry examined the surrounding architecture from three directions: retrieval, execution, and the experience of the agent using its tools.

Retrieval is a sequence of design decisions

Adam Gibson, CTO and Co-founder of Kompile, describes a model-first approach to the full agent lifecycle. His discussion connects retrieval, reranking, knowledge graphs, classification, and routing within a shared architecture. The point is not simply to assemble more components. It is to make their relationships visible enough to optimize the system as a whole.

Retrieval-augmented generation is often described as finding relevant text and passing it to a language model. That short description hides consequential choices. How documents are divided affects what can be retrieved. Ranking affects what reaches the context window. A structured fact may be better obtained through a direct query than reconstructed from similar-looking passages.

For a team diagnosing incorrect answers, these distinctions matter. Was the relevant information absent, overlooked, ranked too low, or misinterpreted after retrieval? Without that separation, “improve the prompt” becomes a response to several different problems.

Execution should create evidence for the next decision

Leonard Lin, CTO and Co-founder of Shisa.AI, describes a development loop that connects specification, implementation, testing, review, and remediation. Structured work records are part of the process: they make it possible to examine where the work slows down and which failures recur.

The implication extends beyond software development. An agent should receive evidence from the environment, such as a validator result or a tool response, that tells it whether its intended action actually happened. A confident description of a completed task is not an execution receipt.

Lin also brings dependency and supply-chain controls into the agent environment. For this article’s purposes, the enduring issue is authority: when a tool can install software or use credentials, its behavior becomes part of the security boundary. The surrounding controls must remain meaningful even when the model’s proposed next step is wrong.

Design tools for the agent’s job

Jason Mooberry, Founder of Sumato AI, calls this design problem AI Experience, or AX. His talk asks how much of an agent’s activity is spent finding its place, rereading files, and recovering from awkward tools rather than advancing the task.

Two examples make the idea tangible. Spath addresses code through symbols rather than relying only on file locations and line numbers. Splan expresses a group of code operations with a target, action, and content, using transactional behavior so a group succeeds together or is not applied.

These examples suggest a broader principle: a tool should match the unit of work the agent is trying to accomplish. If the task is to update a customer’s approved delivery address, a narrowly defined operation can be easier to validate than a sequence of unconstrained edits across several records. That does not remove the need for authorization. It makes authorization and validation easier to attach to a meaningful action.

Foundry’s perspective: trace one business question through the system

Consider an illustrative internal support assistant asked whether a customer is entitled to a replacement. The answer may depend on policy text, a purchase record, and the status of an earlier request. Those are different kinds of evidence and should not automatically follow the same retrieval path.

A first implementation might retrieve policy passages and query the order system through a typed tool. The assistant should identify which policy version applies and preserve the evidence supporting its recommendation. If an order cannot be found, that is an unresolved dependency, not a reason to invent a plausible purchase history.

The action boundary comes next. Recommending a replacement and issuing one are separate capabilities. An approved issuance operation should return an identifier that can be checked later. If the network times out, the system needs to determine whether the operation already succeeded before repeating it.

This is where a promising PoC becomes a business process. The team can examine a failed case and tell whether the problem came from retrieval, policy interpretation, permission, or execution. Each category leads to a different fix. A new model might improve interpretation; it will not resolve an ambiguous business rule or an untraceable transaction.

At Foundry Labs, the relevant engineering perspective is end-to-end ownership: define the evidence, the allowed action, and the result the business can verify. The system around the agent makes that chain inspectable.

Sources and further reading

This article draws on the Beyond the Wrapper - Engineering End-to-End Agentic Systems programme and the talks identified above. Tokyo AI (TAI) connects researchers, engineers, and industry; explore Foundry Labs’ community work for more context.

Talk materials from Adam Gibson, Leonard Lin, and Jason Mooberry are available upon request. Please use our contact form and include the event title and speaker name.

Speaker profiles

Adam Gibson. Co-founder and CTO of Kompile, with a background in deep learning systems. LinkedIn.

Leonard Lin. Co-founder and CTO of Shisa.AI, working on multilingual models and inference systems. LinkedIn.

Jason Mooberry. Founder of Sumato AI. His talk examines interfaces and context for AI-driven work. LinkedIn.

All articles