liteagents/moyai — the LiteLLM A2A Agent Gateway

Read first: 01-research/liteagents-and-moyai-study.md (Min). It is the deeper study — he read the skills, memory and verification docs and got Moyai's actual skills_search / skills_load implementation. This file is the delta from my lane only, not a second opinion on the whole.

I wrote a full study, found Min's already committed, and am not duplicating it. What follows is only what mine adds.

Why this file exists at all

A third party's documentation can change a recorded decision. Two items in mine did, and one of them settles a question Min's study leaves as a recommendation.

1. The delta — LiteLLM's A2A Agent Gateway is a cost ledger we do not have to build

Min's §2.6 notes per-requester cost attribution at the gateway and the line that matters most to me — "a request limit is not a cost limit." What he did not have is the gateway's A2A surface, which is directly our layer.

From docs.litellm.ai/docs/a2a:

And it settles a decision I had recorded as ours to build. My mira-what-we-need-to-look-into.md §3 framed "tier 2: GO before ZEN" as a rule we would have to implement inside 8 agents. A gateway sits where every A2A call passes, so it is a better enforcement point than the agents. That is now the recommendation for core/config/.

This reconciles with Min's §5 rather than contradicting it. He says do not adopt LiteAgents as a second SDK on top of ours — I agree. The gateway is different from the SDK: the SDK would sit between us and the executor, which is his objection; the gateway sits on the inter-agent boundary, which is where our A2A transport already lives.

2. What I would take into core/config/ — as pattern, with the caveat stated

Take the pattern:

1. protocolVersion pinned per agent — V2's declaration/implementation drift was our own defect; pinning it removes the class rather than testing for it.
2. Cost recorded where the request lands, not where it is executed — my ledger spec gains a place to live.
3. A request limit is not a cost limit (Min's §2.6, confirmed in the gateway docs) — GO's binding constraint is a $60 allowance, ZEN's a $40 float, and neither is a request count.
4. cost_state: measured | unknown is not negotiable. liteagents surfaces "available native usage reports" rather than computing a figure; V2's 30,721 rows of $0.00000 are what violating that produces.

Do not take, and here is the honest reason — this is the part Min's study does not cover:

LiteLLM's provider model is provider/model through a LiteLLM gateway key. Young's is Opencode's GO/ZEN. These are different billing worlds.

So adopting it for cost enforcement means either proxying Opencode through LiteLLM, or copying the pattern and not deploying the thing. Both are defensible; neither is decided, and it is not mine to decide.

3. Version-gating is a silent-loss hazard — worth knowing before anyone relies on it

From the gateway docs, and I am recording these because they are exactly the class of thing that quietly eats a correctness claim:

That last one is a fail-quietly behaviour in a component we would be trusting for cost. It is the reason this file ends with "pattern, not dependency."

4. The one item that settles an open question in my own lane

My mira-skills-and-tools-store.md §3 raised: is loading capability-gated or task-driven? and answered capability-gated-with-task-driven-inside.

Min's study §3a found Moyai's actual implementation, and it is better than my answer:

"searches authorized skill names and descriptions with task keywords. At most five matches enter the next model call as metadata; instructions enter context only after skills_load."

So the load model is task-driven search → explicit load, with a hard cap on how many matches enter as metadata. Three properties my draft did not have:

I am adopting this over my own draft. It is a measured implementation of exactly Young's instruction, and it settles the question Min and I both left open. Recorded so my weaker version does not survive by being first.

5. What is still NOT established — mine, stated plainly

• I installed and ran neither tool. Every claim here is from documentation. No probe.
• No cost figure for LiteLLM — I cannot say whether its A2A gateway works with Opencode's endpoints at all. Its world is LiteLLM provider/model + a gateway key; ours is GO/ZEN. The gap between them is unmeasured.
• liteagents is very young — created 2026-09-22, 28 commits, ~21–37 stars, and its v2 replaced the public v1 implementation, with liteagents.legacy kept behind an extra. A dependency this new that has already broken its public API once is a different risk class from the official a2a-sdk, and I would not price them the same.

That last row is me correcting myself: I argued earlier that a2a-sdk's 26-package bill was cheap. This repo is not that. Same "we studied a dependency" reasoning, opposite conclusion, and the difference is the risk class.

6. Net effect on my two lanes

Neither lane needs a new dependency for any of that to be true.