What Is the Mitra Protocol? The Beginner's Guide to Signed Envelopes for AI Agents
CodexFuse Team · 2026-11-05T02:51:21.654Z · 11 min read min read
What is the Mitra Protocol?
The Mitra Protocol is an open-source protocol for AI agents that do not trust each other: it wraps every message between two agents in a signed envelope carrying hard limits — a token budget, a price, and a mandate that caps the cost in dollars. If you searched "what is the mitra protocol" and wondered whether this is a crypto coin or a phone app, here is the short answer: it is neither. Mitra is spelled M-I-T-R-A, and it has no relation to MIRA, the crypto token (M-I-R-A), or to Mitra Link, a consumer phone-assistant feature from a different company entirely. Mitra is developer plumbing for agent-to-agent work.
The protocol was released on GitHub on October 20, 2026, by a developer who goes by mrpkk, as a small MIT-licensed Python package with no required dependencies. Its pitch, in the words of the launch announcement, is that it solves the "between" problem: how two Mitra protocol AI agents that have never met can safely exchange work. In short, Mitra is an agent to agent trust protocol with budgets built into every message.
That is a bigger shift than it sounds. Most agent handoffs today are hand-rolled JSON blobs or free-form text, where the budget is a hope and the identity is a guess. An agent that wakes up to a Mitra envelope instead gets a message it can check before it does anything: who sent it, what the job is, how many tokens it may burn, what it may cost, and cryptographic proof none of that was tampered with. The agents themselves usually run on rented servers — the same VPS hosting developers already rent for side projects — which is exactly where an untrusted handoff hurts most.
What problem does Mitra solve?
Mitra solves the problem of trust between strangers. Inside one process, agents share memory, config, and an operator who set everything up, so trust is cheap. Between two agents — yours and mine, or your research agent and your billing agent — none of that holds.
The launch announcement frames the gap plainly: the agent ecosystem has been obsessed with orchestration inside a single process, while the harder problem is how two agents that have never met can safely exchange work. Without a shared trust anchor, every message is a claim: I am who I say I am, this is what I want, you will be paid. Mitra turns those claims into checks.
The design also targets two failure modes builders actually hit: agent loops that silently drop context and blow out budgets. Both come from the same root cause — context assembly and spending are hopeful suggestions rather than hard constraints. Mitra makes them part of the message itself, so they cannot be quietly lost in transit.
What is inside a Mitra Protocol signed envelope?
A Mitra envelope is a message with the rules attached. Mitra protocol signed envelopes are the unit the whole design is built around: the announcement names the fields every envelope carries — the goal, the task, the recipient, a token budget, a price in USDC, and a mandate with a maximum cost in USD. Here is what each piece does, based on the launch description.
| Envelope field | What it says | Why it matters |
|---|---|---|
| Goal | The outcome the sender wants | Gives the recipient something checkable to refuse or accept |
| Task | The specific work to perform | Narrows what the recipient is authorized to do |
| Recipient | Which agent the envelope is for | Stops messages from being picked up by the wrong agent |
| Token budget | Maximum tokens the work may consume | Turns runaway context growth into a hard, pre-named limit |
| Price in USDC | What the task costs | Puts the cost on the message itself, before work starts |
| Mandate (max cost in USD) | The spending ceiling for the work | The envelope can be refused if the work would exceed it |
A quick note on vocabulary: token budgets, USDC prices, and USD mandates are the protocol's own terms for describing constraints — this article is not a payment recommendation and is not telling you to price anything in crypto.
The mandate field is where the design gets strict in a way builders will recognize. Exceeding a mandate does not return a vague error; the announcement gives an example: the system returns a specific error like 'amount: 50.0 above the mandate of 0.5' instead of a generic boolean. A refusal always names the rule that rejected it, which makes budget failures debuggable instead of mysterious.
How does an agent verify an envelope it does not trust?
Every envelope is signed with Ed25519, and — the clever part — the signer's public key travels inside the envelope itself. That means a receiving agent does not need to phone home to anyone: it can check the signature offline, with no central hub and no shared secret.
The verification arc for a skeptical agent looks like this:
- Read the envelope. Pull out the goal, task, recipient, token budget, price, and mandate before doing any work.
- Check the signature. Use the enclosed public key to verify the Ed25519 signature. If a single byte was changed in transit, verification fails.
- Check the mandate. Confirm the work fits the USD ceiling. If not, refuse with the named rule, as in the 'above the mandate' example.
- Check the budget. Confirm the token budget is acceptable before assembling any context — the budget is a constraint, not a suggestion.
- Do the work, then close out. Only after all four checks pass does the recipient start.
This is the whole trust model in miniature: verify first, spend nothing until the math checks out, and never need the sender's cooperation to do the checking. Anyone skeptical of Mitra Ed25519 agent envelopes — the recipient, an auditor, a third party — runs the same checks independently.
What is Mitra's three-tier memory for?
The three-tier memory exists to stop agents from becoming confidently wrong. The failure mode it targets is silent context truncation: an agent runs long, its context quietly gets cut, and it keeps answering with full confidence from a partial memory.
Mitra splits memory into three tiers by access cost. Hot memory lives in the envelope queue — the fast, immediate context. Warm memory lives in a SQLite database with full-text search, for the recent working record. Cold memory holds artifacts addressed by their SHA256 hash, for everything that can be fetched later by fingerprint. The launch announcement's summary line is worth quoting: 'The context window never grows; instead, the store does, with items fetched only if they fit the budget.'
Notice the budget keeps reappearing. Even memory retrieval is gated by the envelope's token budget, so fetching history cannot itself blow the budget. That is the design theme throughout: the envelope is a bounded unit of work, and everything the agent does with it has to fit inside the bounds.
Memory systems are a busy lane in agent tooling, and they differ in what they promise. For contrast, arvre is a session-navigation approach for browsing and resuming past agent sessions — Mitra's memory tiers are a different job: keeping the working record of one bounded, budgeted envelope intact.
What does the Mitra Protocol conformance suite check?
The announcement describes a conformance suite with ten checks that developers can run against their own implementations with a simple pytest command, so different agents can prove they speak the same protocol.
The announcement names only four of the ten checks explicitly: signatures must be valid, tampering must invalidate signatures, token budgets must be respected, and expired envelopes must not be delivered. The other six checks are not documented in the announcement, so this guide will not invent them. What is stated is enough to see the intent: the suite tests the exact guarantees the envelope makes — identity, integrity, budget, and freshness.
This is the interoperability story. A protocol with one implementation is a library; a protocol with a conformance suite is an invitation. Any team can build a Mitra-compatible hub and run the suite to show it behaves — the signature math, the budget enforcement, and the expiry rules are checkable, not just documented.
Mitra Protocol vs A2A and MCP: how is Mitra different?
Mitra is designed as a complement to both, not a replacement — the launch announcement says so directly: Mitra is 'explicitly not a runtime or hosted platform, but a carrier protocol that can integrate with existing standards like MCP and A2A.' The three standards solve different parts of the agent stack.
| Mitra | MCP | A2A | |
|---|---|---|---|
| Solves | Trust between two agents that have never met | How an agent talks to tools and data | How agents discover and delegate tasks |
| Message unit | Signed envelope with budgets and mandates | JSON-RPC request and response | Task objects through a lifecycle |
| Trust model | Ed25519 signature, public key in the envelope, offline verification | Transport and session security | Agent cards and capability discovery |
| Cost model | Token budget and USD mandate baked into the message | None built in | None built in |
| Status | Solo open-source project, launched October 2026 | Open standard with broad adoption | Open standard with big-vendor backing |
The same lane logic applies to the receipt side of agent trust. AER-1 records verifiable receipts for individual agent tool calls — Mitra's envelope is what carries the budgeted work between agents in the first place. Different functions, no rivalry.
What happened to the Mitra project?
This is where the story gets honest, and a beginner's guide written in November 2026 should not hide it. The October 20 announcement described Mitra as 'explicitly not a runtime or hosted platform' — a pure carrier protocol, a small dependency-free Python package. Since then, the project has evolved.
The current home of the project is github.com/mrpkk/mitracore — 'Mitra Core'. The repository was created on October 20, 2026, the same day as the launch, and as of November 5, 2026, it shows 19 commits, 0 stars, MIT license, and no releases. A follow-up launch piece on October 24 describes the architecture as deliberately split: the open protocol stays MIT-licensed, while a commercial layer — Mitra Core — adds deep artifact verification, mandate engines, and hosted services. The project's own README now lists hosted endpoints at rta.lat, including a verify API with pricing: 20 verifications per day free, $0.005 USDC per verification after that, or $49 per environment per month.
So do not treat the launch announcement's 'not a hosted platform' line as the current state: it described the protocol at birth, and the project has since grown a hosted service around it. If you go looking for the code, do not pip install anything named 'mitra' — the similarly-named mitra-sdk on PyPI is an unrelated Matih API client. The project lives on GitHub under mrpkk/mitracore.
The same author, mrpkk, has since launched a sibling project called soma-protocol — 'memory, obligations and proofs in one MCP endpoint' — which reuses the signed-envelope idea with its own vocabulary and a hosted hub. It is a separate project by the same author, not the same thing as Mitra, and this guide keeps them separate. The developer tools you run alongside any of this — for example Claude Code for agentic coding, or OpenRouter when your agents need many model providers through one key — are their own lanes entirely; Mitra would sit underneath the handoffs between them.
Sources
This guide is based on the sources the writer fetched and read on November 5, 2026. Because the Mitra Protocol is a sixteen-day-old solo project, coverage is thin: the clawdbytes launch announcement is the only press source, and claims below are hedged to match what each source actually says.
1. clawdbytes.com — 'Mitra Protocol Ships Open-Source Standard for Agent-to-Agent Trust and Budgeting' (October 20, 2026 launch piece): release date, author mrpkk, MIT license, 'small... Python package with no required dependencies', the envelope concept (goal, task, recipient, token budget, price in USDC, mandate with max cost in USD), the 'amount: 50.0 above the mandate of 0.5' refusal example, the three-tier memory architecture, Ed25519 signing with the public key inside the envelope, the ten-check conformance suite (four checks named), and the 'explicitly not a runtime or hosted platform' framing.
2. github.com/mrpkk/mitracore — the project's current README and repository metadata (fetched November 5, 2026): the 'Mitra Core' rename, created October 20, 2026, 19 commits, 0 stars, MIT license, the hosted verify/quote/trust-report endpoints at rta.lat, and x402 pricing (20 free verifications per day, $0.005 USDC per verification, $49 per environment per month).
3. clawdbytes.com — 'Soma: Memory and Proofs for AI Agents, Measured Not Asserted' (October 24, 2026): the split between the MIT-licensed open protocol and the commercial 'Mitra Core' layer.
4. dev.to/mrpkk — 'Memory that keeps its word' (October 23, 2026): soma-protocol as a separate sibling project by the same author, with its own envelope vocabulary.
5. Kraken Crypto Asset Statement for Mira Network — confirms Mira (M-I-R-A) is a crypto consensus network with an ERC20 token, unrelated to Mitra.
6. progressiverobot.com — 'Mitra Link: Agent-to-Agent Messaging Permissions' (October 6, 2026): confirms Mitra Link is a consumer phone-assistant feature, unrelated to the protocol.
Frequently Asked Questions
Is the Mitra Protocol the same as the MIRA crypto token?
No. Mitra (M-I-T-R-A) is an open-source protocol for signed agent-to-agent envelopes. MIRA (M-I-R-A) is a crypto token on the Base blockchain for a decentralized AI-verification network. The names sound alike, but the projects share nothing — different authors, different purposes, different technology.
Is Mitra the same as Mitra Link?
No. Mitra Link is a feature of Mitra, a consumer AI phone assistant by founder Sai Mandava, that lets the assistants of people you allow message each other. The Mitra Protocol is an open-source developer protocol by the GitHub user mrpkk for AI agents to exchange signed, budgeted envelopes. Different companies, different products.
How do I install the Mitra Protocol?
Carefully. The project lives on GitHub at github.com/mrpkk/mitracore, not on PyPI — the package named 'mitra-sdk' on PyPI is an unrelated API client. The original launch described a small dependency-free Python package, but the current mitracore repository has its own dependency files, so follow the repository's own setup instructions rather than assuming zero dependencies. As of November 2026 there are no tagged releases.
Does Mitra replace MCP or A2A?
No, and its own announcement says so: Mitra is 'explicitly not a runtime or hosted platform, but a carrier protocol that can integrate with existing standards like MCP and A2A.' MCP handles agent-to-tool context, A2A handles agent-to-agent task delegation and discovery, and Mitra handles trust between the agents — signed envelopes, budgets, and mandates. They are complements.
Is the Mitra Protocol finished?
It is a young, moving project. Launched October 20, 2026, it went from a pure carrier-protocol announcement to a 'Mitra Core' commercial layer with hosted verification endpoints within four days. As of November 5, 2026, the GitHub repository has 19 commits, no releases, and no independent reviews. Treat it as an interesting early experiment in agent trust — worth understanding, not yet something to bet infrastructure on.
