Unified Agent Surface
One conversational interface for operating several of Decklar’s products, through the APIs they already have.
- Where
- At Decklar
- Status
- In progress
- My part
- Working on the architecture and the agent harness: how products become tools, and how the agent’s work runs.
- Built with
- DeepAgents (evaluating)
Decklar has several products for supply chain teams, including CommAgent and DINA. Each has its own interface and API. The idea is one conversation where a user asks for something and an agent does the work across whichever products it needs.
The architecture isn’t settled yet, so this page is about the problems.
The constraint
The agent has to work through the products’ existing public APIs, without changing each product to suit it. So the harness has to find out what each product can do, present all of it to the agent as one consistent set of tools, and bring along the context each product needs.
The runtime
Connecting a model to tools is quick. The work is in the runtime around it: what state a run has, what happens when a tool fails halfway, how to watch, stop, or resume a long run, and when a person must approve a change to production data.
Two design questions shape the rest: what belongs in the agent’s reasoning versus the runtime that carries it out, and how much of that runtime should depend on a framework. I’ve been evaluating harness approaches, including DeepAgents, against both.
Open questions
Permissions: the agent acts for a user, so in each product it should only be able to do what that user can do. Where should that boundary be checked?
Context: a request can touch several products in one run. What should carry from one step to the next, and what should stay inside one product?
Safety: changing data needs approvals, a clear record of what the agent did, and a way to recover when something goes wrong.