Agent Experience
Agents already in production are frequently unreachable by the systems meant to call them, and absent from the registries where buyers and other agents search.
An agent is reached through four things: a protocol another system can speak, a card that declares what it does, a loop that holds context across a long task, and a listing in the place callers actually look. Work that stops at the first of these produces an agent that runs correctly and is never selected. This engagement takes an agent you already run, puts those surfaces in front of it without rewriting it, and measures whether callers now find it and complete work against it.
- Their agents: customer agents, partner agents and enterprise marketplaces
- Agent card: identity, skills and auth, declared where agents look
- Protocol server: A2A, MCP and ACP
- Runtime packages: published where they look
- Your API: unchanged underneath, with the surface in front of it
No rewrite
Surfaces are generated in front of the agent you already run.
Standards
Protocol choice follows your callers, across A2A, MCP and ACP.
Measured reach
Selection by other agents is recorded, not assumed.
Where it applies
An agent already running that outside systems cannot reach, or that is absent from the registries your callers search.
What we measure
Routing invocation: how often a calling agent selects yours from a catalogue, recorded before and after.
What stays untouched
Your agent. The surface is generated in front of the entrypoint you already run.
Discovery is a prerequisite for use.
Fit
Who calls your agent
Products with a working agent that stops at the edge of their own infrastructure, or that owe partners a declared interface.
Internal platforms
Other teams and vendors need a standard way in
Partner integrations
Every new caller costs custom work today
Long-running tasks
Work fails partway when the loop forgets
Enterprise listing
Absent from the galleries buyers browse
Scope
Where agent experience breaks, and how we address each
An agent that runs correctly and is never selected produces no value. Each row below is measurable, and the tooling behind every response is open source we maintain and you keep.
What an agent is reached through
Work that stops at the first of these produces an agent that runs correctly and is never selected.
- 01ProtocolA2A, MCP or ACP
- 02Cardidentity, skills, auth
- 03Loopcontext across a long task
- 04Listingwhere callers search
- 05Selectionmeasured, not assumed
| The problem | How we address it |
|---|---|
| No external system can call it | A conformant server and Agent Card are generated in front of the entrypoint you already run, across any of the eight frameworks SuperOptiX supports. The agent itself is not modified. |
| Absent from the registries callers search | Publication to the registries, hubs and enterprise galleries your callers use, with the listing and compliance material each channel requires. |
| Never selected, blamed on quality | Routing invocation is measured directly: how often a calling agent picks yours from a catalogue of candidates, given queries it should handle. An agent nobody routes to has a completion rate nobody observes. |
| Card written as docs, read as an interface | The description is optimized with GEPA against selection outcomes, so it is tuned for the agent reading it rather than for a human skimming it. |
| Every caller needs bespoke integration | One declared surface per protocol replaces per-partner effort, across A2A, MCP and ACP, chosen by who is calling you rather than by preference. |
| Long tasks lose context partway | Memory that outlives a single request, with ranking and summarization tuned as one layer and a documented recovery path mid-task. |
| Retrieval never adapted for outside callers | A retrieval layer scored on what the agent actually reads, optimized against your vector store rather than on retrieval metrics alone. |
| Conformance asserted, never demonstrated | Surfaces are checked against the official Technology Compatibility Kit and live clients, so conformance is a result you can reproduce. |
| Identity and auth undeclared | The card declares identity, skills and auth explicitly, with signed cards where the channel requires cryptographic verification. |
| No way to tell if distribution worked | Routing invocation is recorded before and after, and the result is written to an Agent Quality Record that remains auditable. |
Process
How we work
Experience review
We call the agent as an outside caller would, and record where discovery, authentication, context or recovery breaks. Selection is measured alongside completion, so an agent that is never chosen is distinguished from one that fails the work.
Protocol layer
A conformant server and Agent Card generated in front of your existing entrypoint, with identity, skills and auth declared, and conformance checked against the official test kit and live clients.
Loop, memory and retrieval
Context assembly, memory that outlives a single call, retrieval tuned on what the agent reads, and clean recovery mid-task, all inside the runtime your team already operates.
Distribution and measurement
Publication to the registries and galleries your callers use, with the card description optimized by GEPA against selection outcomes, and routing invocation recorded before and after.
Deliverables
What you receive
Scope is set from your requirements rather than from a fixed package. Whatever is agreed at the outset is built in front of the agent you already run, measured against callers that behave like your real ones, and handed over on open source your team keeps.
Declared capability
An agent card stating identity, skills and auth, published where callers look
Protocol surfaces
Working implementations matched to your callers, checked against live clients
Loop behaviour
Memory, context and recovery, so a long task finishes unattended
Discoverability
Presence in the registries and galleries where callers go looking
Scope
Engagement Options
Three columns, scoped and bought independently. Protocols and Loop are usually taken together, since a surface that callers can reach still needs a loop that finishes the work. Scope and cost are quoted against your systems once we have seen them.
Typical starting point
Agent Protocols
A declared interface for callers
Typically 4 to 6 weeks
One or more protocol surfaces
One declared interface, identity and skill set, replacing a pile of one-off integrations.
- A2A for agent-to-agent work
- MCP for tools and resources
- ACP for agent and editor integration
- Agent card declaring skills and auth
- Conformance checked against live clients
- Versioning and deprecation plan
Agent Loop
Memory, context and recovery
Typically 4 to 6 weeks
Loop, memory and runtime
Control flow, memory that outlives a single call, and clean recovery mid-task.
- Loop design and control flow
- Context assembly and compaction
- Recovery when a step fails
- DSPy, OpenAI, Claude SDK, Google ADK, Pydantic AI, CrewAI, DeepAgents, Microsoft
- Main coding-agent harnesses supported
Agent Marketplace
Listing and discovery
Typically 2 to 4 weeks per channel
Per distribution channel
One protocol implementation, reaching every enterprise platform that speaks it.
- Enterprise gallery and registry submission
- Framework plugin or capability package published
- Discovery over A2A and MCP
- Listing assets, metadata and compliance material
- Update and maintenance path
Open source
Underlying systems
Our protocol and framework work is public. Engagements build on what you have.
Questions
Questions
Discuss Agent Experience
Tell us what your product exposes today and which agents you want reaching it.
London and San Francisco. Remote or on site.