DEV Community: Rudson Kiyoshi Souza Carvalho

TERSE Tool Catalog (TTC): Cut Tool Catalog Token Usage by 66.6% in Your AI Agents

Rudson Kiyoshi Souza Carvalho — Tue, 05 May 2026 15:14:53 +0000

If you’ve ever built or worked with AI agents that use tools via the Model Context Protocol (MCP), you’ve probably felt the pain that nobody talks about out loud:

The tool catalog is eating your entire context window and budget.

A single tool defined in MCP JSON Schema typically consumes 100–270 tokens. With 50 tools installed, you’re already spending 5,000–13,500 tokens before the user even writes their first message.

This isn’t just expensive — it actively hurts performance:

Higher cost on every single request
Lower tool-selection accuracy as the catalog grows (attention dilution)
Less room for actual user instructions, memory, or reasoning

The good news? There’s a clean, elegant solution: TERSE Tool Catalog (TTC).

The Problem with Today’s MCP JSON Schema

The current MCP format was designed for machine-to-machine execution contracts, not for LLM reasoning. As a result:

There is no explicit trigger condition (WHEN) — the LLM has to guess from a free-form description string.
There is no error contract (ERR) — the model has no idea what to do when a tool fails.
There is no retrieval taxonomy (TAGS) — dynamic tool retrieval (RAG over tools) becomes painful.
Verbose parameter descriptions add noise with almost zero signal for the LLM.

The result is high cost + mediocre tool selection.

Introducing the TERSE Tool Catalog (TTC)

TTC is an official extension of the TERSE Format — a specification for dense, deterministic, human-and-machine-readable representations optimized for LLMs.

It is not just a compression of MCP JSON. It is a semantic reformulation of the tool contract.

TTC keeps everything the LLM actually needs for execution and adds three fields that MCP is missing:

PURPOSE — clear one-line intent
WHEN — explicit semantic trigger (the most important field for selection)
ERR — declared failure modes
TAGS — taxonomy for semantic grouping and retrieval

Measured result: average 66.6% token reduction with net information gain.

TTC Syntax — Clean and Simple

TOOL <tool-id>
  PURPOSE: <one-line description of what the tool does>
  IN: <param1>:<type>, <param2>:<type>?
  OUT: <return-type>
  ERR: <error1> | <error2> | <error3>
  WHEN: <natural language trigger condition>
  TAGS: <tag1>, <tag2>, <tag3>

Supported Types

string, int, float, bool
array[string], array[int], etc.
object, any

The ? suffix marks an optional parameter.

Real-World Example: `gmail_send_email`

MCP JSON Schema (208 tokens):

{
  "name": "gmail_send_email",
  "description": "Sends an email message via the Gmail API to one or more recipients...",
  "input_schema": { ... }  // very verbose
}

TTC (55 tokens):

TOOL gmail_send_email
  PURPOSE: send email via Gmail
  IN: to:string, subject:string, body:string, cc:string?
  OUT: message_id:string
  ERR: auth_failed | quota_exceeded | invalid_recipient
  WHEN: user wants to send or compose an email
  TAGS: gmail, email, communication

Same semantic content. 73.6% fewer tokens. And the LLM now has structured fields to make much better decisions.

Real Benchmark (10 Production Tools)

Tool	JSON Schema	TTC	Reduction
gmail_send_email	208	55	73.6%
gmail_read_inbox	121	52	57.0%
drive_list_files	141	53	62.4%
calendar_create_event	262	78	70.2%
slack_send_message	206	69	66.5%
github_create_issue	269	84	68.8%
...	...	...	...
TOTAL (10 tools)	1948	650	66.6%

Projection at scale:

50 tools → ~9,740 → ~3,250 tokens
100 tools → ~19,480 → ~6,500 tokens Savings: ~13,000 tokens per request

Why TTC Works So Well

It follows the core TERSE principles:

Maximum information density per token
Determinism (same input → same output)
Human + machine readability
Full composability (tools → servers → agent context)

And it adds exactly what LLMs need for better reasoning:

WHEN becomes the primary discriminator for tool selection
ERR enables graceful degradation and fallback strategies
TAGS makes dynamic tool retrieval (RAG over tools) trivial

How to Use It in Your Agent Context

At the start of a conversation (or via dynamic retrieval), you inject:

TOOLS v1.0 [3/47]
  MCP gmail v1.2
    TOOL gmail_send_email
      ...
  MCP google_drive v2.0
    TOOL drive_read_file
      ...

With semantic tool retrieval, you only inject the 3–5 most relevant tools per request. Context cost becomes sub-linear no matter how large your total catalog grows.

Reference Converter (Python)

The author provides a ready-to-use reference implementation:

github.com/RudsonCarvalho/terse-format

It converts MCP JSON Schema → TTC with sensible defaults. For production use, you simply add explicit annotations for OUT, ERR, WHEN, and TAGS on the server side.

Planned Future Extensions

EXAMPLE block — input/output examples for few-shot learning
COST annotation — estimated token/latency cost per call
CHAIN annotation — tool dependencies and composition patterns
ALIAS field — alternative trigger phrases
AUTH annotation — required OAuth scopes

Conclusion

The TERSE Tool Catalog is not just a token-saving trick. It is a genuine improvement in agent quality — better tool selection, better error handling, and native support for semantic tool retrieval.

If you work with agents, MCP, LangGraph, CrewAI, AutoGen, or any modern agentic framework, TTC is worth trying today.

Links

📄 Full spec (Zenodo): https://doi.org/10.5281/zenodo.19869007

💻 GitHub: https://github.com/RudsonCarvalho/terse-format/tree/main/extensions/ttc

🌐 Landing page: https://rudsoncarvalho.github.io/terse-format/

📦 TERSE Format (parent spec): https://doi.org/10.5281/zenodo.19058364

Your AI agent wastes 13,000 tokens before saying "hello"

Rudson Kiyoshi Souza Carvalho — Wed, 29 Apr 2026 01:22:37 +0000

And you probably have no idea.

If you have an agent with 50 MCP tools installed, here's what happens before any user message is processed:

{
  "name": "gmail_send_email",
  "description": "Sends an email message via the Gmail API to one or more 
    recipients. Use this tool when the user explicitly requests to send, 
    compose and send, or deliver an email message to someone.",
  "input_schema": {
    "type": "object",
    "required": ["to", "subject", "body"],
    "properties": {
      "to": {
        "type": "string",
        "description": "The recipient email address or comma-separated list"
      },
      "subject": {
        "type": "string",
        "description": "The subject line of the email"
      },
      "body": {
        "type": "string",
        "description": "The body content of the email in plain text or HTML"
      }
    }
  }
}

That's ~195 tokens. Per tool. Before anything else.

50 tools × 195 tokens = 9,750 tokens of pure overhead.

And that's just the catalog. You haven't touched user context, conversation history, documents, or anything useful yet.

"But there's prompt caching, right?"

Yes. It reduces the financial cost to ~10% of the base rate.

But caching does not reduce attention cost.

Those tokens still occupy the context window. The model still attends to all of them on every request. And if you use dynamic tool retrieval — selecting different tools per request based on user intent — the cache breaks on every different selection.

The bill doesn't disappear. It just gets cheaper.

The real problem nobody talks about

MCP JSON Schema was designed as a tool execution contract. Not as a semantic tool selection contract.

The result: information critical for LLM reasoning is either absent or buried in free-form text:

No error contract — the LLM doesn't know what to do when auth_failed
No explicit trigger — it has to infer "when to use this tool" from a paragraph of description
No retrieval taxonomy — no standard way to group or filter tools by domain

Verbose AND semantically incomplete. The worst of both worlds.

TTC — TERSE Tool Catalog

I spent the last few weeks solving this problem. The result is an extension of the TERSE Format called TTC — TERSE Tool Catalog.

The same tool above in TTC:

TOOL gmail_send_email
  PURPOSE: send email via Gmail
  IN: to:string, subject:string, body:string, cc:string?
  OUT: message_id:string
  ERR: auth_failed | quota_exceeded | invalid_recipient
  WHEN: user wants to send or compose an email
  TAGS: gmail, email, communication

~55 tokens. 73.6% reduction.

And notice what was added, not just removed:

Field	MCP JSON	TTC
ERR — failure contract	❌ absent	✅ explicit
WHEN — selection trigger	❌ buried	✅ explicit
TAGS — retrieval taxonomy	❌ absent	✅ explicit

It's not compression. It's reallocation.

This is the most important point in the spec:

TTC does not reduce tokens by removing semantic content. It reduces syntactic and documentary overhead from JSON Schema — which serves human readability, not LLM reasoning — and reinvests part of those savings into explicit tool-selection semantics.

The actual math:

MCP JSON Schema:         ~195 tokens per tool
TTC without new fields:   ~35 tokens
TTC with all fields:      ~65 tokens

The 30-token "reinvestment" buys:
  ERR  → failure contract (absent from MCP)
  WHEN → selection trigger (absent from MCP)
  TAGS → retrieval taxonomy (absent from MCP)

Result: 195 → 65 tokens. -66.6%.
But those 65 tokens carry higher reasoning signal
than the original 195.

This is net reasoning-signal gain — not information gain in the classical sense. A critic might say you removed content (parameter descriptions, JSON Schema constraints). Correct. Content that serves human documentation, not LLM inference.

Real benchmark — 10 measured tools

Measured with BPE tokenizer (cl100k_base) on 10 real MCP tool definitions:

Tool	JSON Schema	TTC	Reduction
gmail_send_email	208	55	73.6%
calendar_create_event	262	78	70.2%
github_create_issue	269	84	68.8%
jira_create_ticket	254	77	69.7%
slack_send_message	206	69	66.5%
Total (10 tools)	1,948	650	66.6%

Projections for larger catalogs:

Catalog size	JSON Schema	TTC	Absolute saving
20 tools	~3,896	~1,300	~2,596 tokens
50 tools	~9,740	~3,250	~6,490 tokens
100 tools	~19,480	~6,500	~12,980 tokens

The absolute saving grows linearly. The larger the catalog, the higher the ROI.

Normative WHEN vocabulary

A natural language field without a standard creates another problem: two independent MCP server authors write incompatible WHEN conditions, degrading selection accuracy in large catalogs.

TTC v1.0 solves this with a normative vocabulary:

WHEN: user [wants|requests|asks|needs|intends] to [action] [object]

Conformant examples:
  WHEN: user wants to send an email message
  WHEN: user requests to list files in Google Drive
  WHEN: user needs to create a calendar event

Non-conformant:
  WHEN: send email          ← missing intent verb
  WHEN: user email          ← missing action verb

Accuracy simulation (TF-IDF cosine similarity, 12 tools, 36 queries):

Condition	Accuracy
MCP free-form description	63.9%
TTC WHEN controlled vocabulary	72.2%
Delta	+8.3 pp

Caveat: TF-IDF simulation, not a real LLM benchmark. Directional evidence.

Where it works best

✅ Large catalogs (20+ tools) — where absolute savings justify migration

✅ Local and smaller models — Qwen 7B, Llama 3, Mistral — no cache, narrow windows

✅ Multi-agent pipelines — overhead compounds with every context handoff

✅ RAG over tools — compact TTC is ideal for vector DB indexing and subset injection

❌ Small catalogs with large LLM and wide context — marginal gain

❌ Replacing JSON Schema in API execution contracts — not the use case

Seu agente de IA está desperdiçando 13.000 tokens antes de dizer "oi"

Rudson Kiyoshi Souza Carvalho — Wed, 29 Apr 2026 01:22:14 +0000

E você provavelmente nem sabe disso.

Se você tem um agente com 50 tools MCP instaladas, aqui está o que acontece antes de qualquer mensagem do usuário ser processada:

{
  "name": "gmail_send_email",
  "description": "Sends an email message via the Gmail API to one or more 
    recipients. Use this tool when the user explicitly requests to send, 
    compose and send, or deliver an email message to someone.",
  "input_schema": {
    "type": "object",
    "required": ["to", "subject", "body"],
    "properties": {
      "to": {
        "type": "string",
        "description": "The recipient email address or comma-separated list"
      },
      "subject": {
        "type": "string", 
        "description": "The subject line of the email"
      },
      "body": {
        "type": "string",
        "description": "The body content of the email in plain text or HTML"
      }
    }
  }
}

Isso é ~195 tokens. Por ferramenta. Antes de qualquer coisa.

50 tools × 195 tokens = 9.750 tokens de overhead puro.

E isso é só o catálogo. Ainda não chegou no contexto do usuário, na memória da conversa, nos documentos, em nada.

"Mas tem prompt caching, não?"

Sim. E reduz o custo financeiro para ~10% do valor original.

Mas caching não reduz o custo de atenção.

Esses tokens continuam ocupando a janela de contexto. O modelo ainda processa tudo na atenção a cada request. E se você usa retrieval dinâmico de tools — selecionando ferramentas diferentes por request — o cache quebra em cada seleção diferente.

A conta não some. Ela só fica mais barata.

O problema real que ninguém fala

O MCP JSON Schema foi projetado como contrato de execução de ferramenta. Não como contrato semântico de seleção.

Resultado: informação crítica para o LLM raciocinar está ausente ou enterrada em texto livre:

Sem contrato de erro — o LLM não sabe o que fazer quando auth_failed
Sem trigger explícito — tem que inferir "quando usar essa tool" de uma description de parágrafo
Sem taxonomia de retrieval — não tem como agrupar ou filtrar tools por domínio

Ou seja: verboso E semanticamente incompleto. O pior dos dois mundos.

TTC — TERSE Tool Catalog

Passei as últimas semanas resolvendo esse problema. O resultado é uma extensão do TERSE Format chamada TTC — TERSE Tool Catalog.

A mesma ferramenta acima em TTC:

TOOL gmail_send_email
  PURPOSE: send email via Gmail
  IN: to:string, subject:string, body:string, cc:string?
  OUT: message_id:string
  ERR: auth_failed | quota_exceeded | invalid_recipient
  WHEN: user wants to send or compose an email
  TAGS: gmail, email, communication

~55 tokens. Redução de 73.6%.

E repara no que foi adicionado, não só no que foi removido:

Campo	MCP JSON	TTC
ERR — contrato de falha	❌ ausente	✅ explícito
WHEN — trigger de seleção	❌ enterrado	✅ explícito
TAGS — taxonomia de retrieval	❌ ausente	✅ explícito

Não é compressão. É realocação.

Esse é o ponto mais importante do spec, e vale deixar claro:

TTC não economiza tokens removendo conteúdo semântico. Ele elimina overhead sintático e documental do JSON Schema — que serve legibilidade humana, não raciocínio de LLM — e reinveste parte dessa economia em semântica explícita de seleção de ferramentas.

A conta real:

MCP JSON Schema:        ~195 tokens por tool
TTC sem campos novos:    ~35 tokens
TTC com todos os campos: ~65 tokens

Os 30 tokens de "reinvestimento" compram:
  ERR  → contrato de falha (ausente no MCP)
  WHEN → trigger semântico (ausente no MCP)  
  TAGS → taxonomia de retrieval (ausente no MCP)

Resultado: 195 → 65 tokens. -66.6%.
Mas os 65 tokens carregam mais sinal de raciocínio
do que os 195 originais.

É ganho líquido de sinal de raciocínio, não ganho de informação no sentido clássico.

Benchmark real — 10 tools medidas

Medi com tokenizador BPE (cl100k_base) em 10 definições reais de tools MCP:

Tool	JSON Schema	TTC	Redução
gmail_send_email	208	55	73.6%
calendar_create_event	262	78	70.2%
github_create_issue	269	84	68.8%
jira_create_ticket	254	77	69.7%
slack_send_message	206	69	66.5%
Total (10 tools)	1.948	650	66.6%

Projeção para catálogos maiores:

Catálogo	JSON Schema	TTC	Economia
20 tools	~3.896	~1.300	~2.596 tokens
50 tools	~9.740	~3.250	~6.490 tokens
100 tools	~19.480	~6.500	~12.980 tokens

A economia absoluta cresce linearmente. Quanto maior o catálogo, maior o ROI.

Vocabulário normativo para WHEN

Um campo de linguagem natural sem padrão cria outro problema: dois autores de servidores MCP diferentes escrevem WHEN de formas incompatíveis, degradando a acurácia de seleção em catálogos grandes.

O TTC v1.0 resolve isso com vocabulário normativo:

WHEN: user [wants|requests|asks|needs|intends] to [ação] [objeto]

Exemplos conformantes:
  WHEN: user wants to send an email message
  WHEN: user requests to list files in Google Drive
  WHEN: user needs to create a calendar event

Não-conformante:
  WHEN: send email          ← falta verbo de intenção
  WHEN: user email          ← falta verbo de ação

Simulação de acurácia (TF-IDF cosine similarity, 12 tools, 36 queries):

Condição	Acurácia
MCP description livre	63.9%
TTC WHEN vocabulário controlado	72.2%
Delta	+8.3 pp

Caveat: simulação TF-IDF, não benchmark real com LLM. Evidência direcional.

Onde funciona melhor

✅ Catálogos grandes (20+ tools) — onde a economia absoluta justifica a migração

✅ Modelos locais e menores — Qwen 7B, Llama 3, Mistral — sem cache, janelas estreitas

✅ Pipelines multi-agente — o overhead se acumula a cada passagem de contexto

✅ RAG de tools — TTC compacto é ideal para indexar em vetor DB e injetar subsets

❌ Catálogos pequenos com LLM grande e contexto amplo — ganho marginal

❌ Substituir JSON Schema em contratos de API — não é o propósito

COA-MAS v2: A Meta-Framework for Cross-Domain Multi-Agent Governance

Rudson Kiyoshi Souza Carvalho — Wed, 01 Apr 2026 23:29:15 +0000

AI agents are crossing organizational boundaries. They call tools in partner domains, delegate tasks to external services, and operate in chains where no single actor sees the full picture.

COA-MAS v1 solved the intra-domain governance problem — a four-layer architecture, the Action Claim contract, and the AASG enforcement boundary that ensures zero cognitive load at runtime. If you haven't read it, the paper is at doi.org/10.5281/zenodo.19057202.

The cross-domain problem is different. And it took a full architectural pivot to solve it correctly.

The Silver Bullet Fallacy

Early iterations of COA-MAS v2 tried to build a universal calibration mechanism — a way to translate risk scores between domains with different semantic spaces. After several rounds of debate and stress-testing, it became clear that this approach has the same flaw as trying to replace PIX, TED, wire transfers, and letters of credit with a single payment instrument.

Each of those instruments exists because different transaction contexts require different guarantees. Resilience in distributed systems comes from routing to the right pattern based on context — not from finding the pattern that works everywhere.

The Thesis

COA-MAS v2 is a meta-framework, not a protocol. It standardizes one thing: the Action Intent — a universal artifact that any federated governance pattern can consume. The choice of execution topology is delegated to a Pattern Selection Protocol negotiated during trust peering.

The Action Intent is the common currency. The federation mode is the exchange mechanism.

The Action Intent

The Action Intent is the "passport" of the COA-MAS federation. It is a standardized, cryptographically signed declaration of:

Who is acting — SPIFFE identity, delegation chain, GOV-RISK attestation
What they intend to do — tool URI, operation type, resource scope
What effect they declare — reversibility, estimated scope, data sensitivity
Cryptographic binding — ephemeral DPoP public key for proof-of-possession

Domain A's internal policy, prompts, and risk weights are never transmitted. Only the declared intent, authenticated by Domain A's governance layer.

If Domain A lies — declares bounded_set but attempts a full-table deletion — the signed intent becomes irrefutable forensic evidence. The problem moves from governance mathematics to organizational accountability, backed by cryptographic proof.

The canonical JSON Schema is published at doi.org/10.5281/zenodo.19376419.

The Four Federation Modes

The Pattern Selection Protocol routes each cross-domain interaction to the appropriate mode based on trust distance, acceptable latency, and cognitive burden tolerance.

Mode 0 — Intra-Domain (COA-MAS V1)
Same domain. Deterministic, microsecond latency, zero external dependencies. The foundation everything else builds on.

Mode 1 — Sovereign Visa
Domain A submits the Action Intent to Domain B's authorization endpoint. Domain B's GOV-RISK evaluates it using its own Executable Culture — full sovereignty, no calibration across semantic spaces. GOV-RISK-B issues a standard COA-MAS v1 Action Claim with DPoP binding. AASG-B validates a locally-trusted signature at runtime. Zero cognitive load.

Mode 2 — Ambassador
Domain B doesn't expose tools to foreign agents at all. It exposes an agent communication interface. Domain A's intent becomes the opening message of an A2A conversation. Domain B's Ambassador agent formulates its own plan, submits it to GOV-RISK-B via Mode 0, and executes locally. Maximum isolation. Non-deterministic latency.

Mode 3 — Clearinghouse
A neutral Domain C — a regulated hub both domains trust — evaluates the intent and issues a universally-accepted Action Claim. Appropriate for regulated industries (Open Finance, healthcare prior authorization). Opt-in only: it trades polycentric sovereignty for operational simplicity.

Future Mode 4 — ZK-Policy
The CAGA-compliant target. Domain A generates a zero-knowledge proof of correct policy execution without revealing internal data. Domain B verifies mathematically. Not implementable in production today due to ZKML hardware constraints — but the meta-framework is explicitly designed to incorporate it as Mode 4 when viable, without requiring changes to the Action Intent schema or SPIFFE infrastructure.

The Pattern Selection Protocol

Domains don't negotiate a single mode — they negotiate a Federation Policy that maps operation families and resource classes to modes:

{
  "mode_by_operation": {
    "read":      { "mode": 1, "ttl_seconds": 1800, "single_use": false },
    "delete":    { "mode": 1, "ttl_seconds": 120,  "single_use": true  },
    "configure": { "mode": 2 }
  },
  "mode_by_resource_class": {
    "pii":       { "mode": 2 },
    "regulated": { "mode": 3 }
  }
}

The same pair of domains can use Mode 1 for routine reads and Mode 2 for infrastructure operations — without renegotiating the peering relationship.

Positioning Against CAGA

Meyman [SSRN 6299461] formalizes the Cross-Agent Governance Alignment (CAGA) problem and identifies zero-knowledge proofs as the theoretically correct solution. COA-MAS v2 is the operationally deployable answer while ZKML hardware matures — trading full policy confidentiality for sub-millisecond runtime enforcement, zero integration cost for Domain B, and compatibility with stochastic LLM-based GOV-RISKs.

The relationship is complementary. CAGA defines what a correct solution must prove. COA-MAS v2 defines how production systems navigate the space between the theoretically ideal and the operationally deployable.

What's Published

📄 Working Paper v0.3
doi.org/10.5281/zenodo.19376738
zenodo.org/records/19376739

🔧 Action Intent Schema v1.0.0
doi.org/10.5281/zenodo.19376419
zenodo.org/records/19376420

📚 COA-MAS v1 (foundation)
doi.org/10.5281/zenodo.19057202

If you're building cross-domain multi-agent systems and the governance layer is an afterthought, the meta-framework and the schema are open access. Feedback, critique, and stress-testing welcome.

AI Agents Can Delete Your Production Database. Here's the Governance Framework That Stops Them.

Rudson Kiyoshi Souza Carvalho — Tue, 31 Mar 2026 12:51:25 +0000

This article presents COA-MAS — a governance framework for autonomous agents grounded in organizational theory, institutional design, and normative multi-agent systems research. The full paper is published on Zenodo: doi.org/10.5281/zenodo.19057202

The Problem No One Is Talking About

Something unusual happened in early 2026. The IETF published a formal Internet-Draft on AI agent authentication and authorization. Eight major technology companies released version 1.0 of the Agent-to-Agent Protocol. And a widely-read post demonstrated why the prevailing credential model for AI agents was structurally broken.

The convergence wasn't coincidental. It was the signal that a structural problem — long present in early agentic deployments — had reached the threshold of production consequence.

We've built agents that can:

Delete production databases
Execute financial transactions
Modify business logic
Spawn other agents

And we gave them API keys.

An API key authorizes access. It does not authorize a specific action with a specific impact in a specific context. That distinction is the entire problem.

The Structural Failure Mode: Distributed Cognitive Chaos

I call this failure mode Distributed Cognitive Chaos (DCC): the structural consequence of deploying agents without formal authority hierarchies, authorization contracts, or enforcement boundaries.

DCC has three symptoms:

Action hallucination — an agent executes an action it was never authorized to perform, because nothing formally defined "authorized"
Mandate drift — through a chain of agent-to-agent delegations, the original human intent gets distorted beyond recognition
Accountability collapse — when something goes wrong, there is no tamper-evident record connecting the action to the authority that (supposedly) permitted it

This is not a new problem. It's the oldest problem in organizational theory: how do you coordinate partially autonomous actors toward collective goals while preventing any individual actor from harming the collective?

Herbert Simon identified it in 1947. Elinor Ostrom solved it in 1990. We just haven't applied those solutions to AI agents yet.

COA-MAS: A Governance Framework Grounded in Theory

COA-MAS (Cognitive Organization Architecture for Multi-Agent Systems) is my answer. It synthesizes four intellectual traditions:

Simon's bounded rationality → why agents need external governance
Ostrom's institutional design principles → how to structure governance for durability
Normative multi-agent systems research → how to formalize governance as computable norms
Sociotechnical systems theory → how to make social norms technically enforceable

The framework has three components. Each answers a different question.

Component 1: The Four-Layer Architecture

Question: Who is in charge?

Think of it as a corporate structure for AI agents:

┌─────────────────────────────────────────────┐
│ LAYER 4 — STRATEGIC ORCHESTRATION                  │
│ Receives human objectives · decomposes into tasks  │
└─────────────────────────────────────────────┘
                        ↕
┌─────────────────────────────────────────────┐
│ LAYER 3 — COGNITIVE GOVERNANCE                     │
│ Evaluates proposed actions · issues authorization  │
│ documents · maintains audit ledger                 │
└─────────────────────────────────────────────┘
                        ↕
┌─────────────────────────────────────────────┐
│ LAYER 2 — FUNCTIONAL SPECIALIZATION                │
│ Domain agents · execute tasks within their         │
│ cognitive authority boundary                       │
└─────────────────────────────────────────────┘
                        ↕
┌─────────────────────────────────────────────┐
│ LAYER 1 — EXECUTABLE CULTURE (Constitutional)      │
│ Versioned YAML policies · weights · thresholds     │
│ Human-authored before runtime. Immutable during.   │
└─────────────────────────────────────────────┘

The critical insight, drawn from both Simon and Ostrom, is the separation between those who propose actions and those who authorize them. An agent cannot authorize its own actions. This mirrors the principle of checks and balances in constitutional systems: the body that proposes is not the body that authorizes is not the body that records.

Component 2: The Action Claim

Question: What exactly is the agent authorized to do?

An Action Claim is a formal authorization document that agents must present before executing any real-world action. It's analogous to a building permit — not just "you're allowed to build," but: the location, the dimensions, the materials, the timeline, the inspector, and the version of the building code that governed the approval.

The Action Claim has three parts:

{
  // DECLARED FIELDS — filled by the agent
  "proposed_transition": "DELETE expired sessions older than 90 days",
  "originating_goal": "scheduled maintenance task #4421",
  "delegation_chain": ["human:ops-team", "agent:orchestrator-01", "agent:db-cleaner"],
  "estimated_impact": {
    "destructivity": 0.25,
    "data_exposure": 0.00,
    "resource_consumption": 0.30,
    "privilege_escalation": 0.00,
    "logic_integrity": 0.05,
    "recursive_autonomy": 0.10
  },

  // DERIVED FIELDS — filled by GOV-RISK (Layer 3)
  "justification_gap": 0.08,
  "decision": "APPROVE",
  "governance_signature": "sha256:a3f9...",
  "policy_digest": "sha256:1b2c...",

  // AUDIT FIELDS — filled by infrastructure
  "ac_id": "ac-2026-03-31-00421",
  "state": "AUTHORIZED",
  "committed_at": "2026-03-31T14:22:01Z"
}

The tripartite structure reflects Ostrom's principle of separating operational decisions from the collective-choice rules that govern them. The agent operates at the operational level; Layer 3 applies institutional norms; the audit trail creates an immutable record connecting every decision to the rules that governed it.

Component 3: The AASG (Autonomous Agent Security Gateway)

Question: How is authorization enforced?

Think of the AASG as a customs inspector at the boundary between the agents' cognitive world and the real world of executing tools.

Agent Cognition (A2A) ────────────────► Real World (MCP)
                              │
                         [ AASG ]
                              │
                    Checks exactly 3 things:
                    1. Is the Action Claim valid and signed?
                    2. Is the agent identity correct?
                    3. Does the actual tool call match 
                       what was declared?

The AASG is a physically separate process — not a library in the agent, not a plugin in the MCP server. This separation is the architectural expression of Simon's insight: governance constraints must be external to the decision-maker they constrain. An agent cannot reliably police itself.

What happens when an agent lies?

Consider an agent authorized to clean up expired sessions. It gets an AUTHORIZED Action Claim with destructivity: 0.25. Then it tries to execute:

DELETE FROM users  -- no WHERE clause

The AASG projects the actual tool call onto the governance space:

Declared: destructivity = 0.25 (bounded deletion)
Actual:   destructivity = 1.00 (full table wipe)

Congruence delta: 0.75 >> threshold (0.20)
→ ERR_AASG_003: CONGRUENCE_VIOLATION
→ Action never reaches the database
→ Merkle Ledger: INTERCEPTED entry recorded
→ GOV-AUDIT: SCOPE_SUBDECLARATION_DETECTED alert

The action is blocked before any damage occurs — not discovered in a log review afterward.

The Justification Gap: The First Computable Proportionality Metric

The core innovation in COA-MAS is the Justification Gap — a metric that answers: is this specific action proportional to the mandate that authorized it?

The governance space has six dimensions:

Dimension	What It Measures	Weight
d₁ Destructivity	Irreversible state change (DELETE, DROP, PURGE)	0.30
d₂ Data Exposure	Cross-zone data movement, PII handling	0.25
d₃ Resource Consumption	Financial/computational impact	0.10
d₄ Privilege Escalation	IAM creation, credential access	0.20
d₅ Logic Integrity	Business logic modification	0.10
d₆ Recursive Autonomy	Sub-agent spawning, delegation depth	0.05

The formula:

Gⱼ(V_A, V_M) = Σ wᵢ · φ(aᵢ, mᵢ)

where φ(aᵢ, mᵢ) =
  0               if aᵢ ≤ mᵢ   (within mandate)
  ((aᵢ - mᵢ)/mᵢ)² if aᵢ > mᵢ  (quadratic penalty)
  +∞              if aᵢ > 0 ∧ mᵢ = 0  (absolute prohibition)

The decision:

Gⱼ ≤ 0.15  →  APPROVE
0.15 < Gⱼ ≤ 0.40  →  ESCALATE (human review with full dossier)
Gⱼ > 0.40 or Gⱼ = +∞  →  BLOCK

The quadratic penalty means small excesses may be tolerable, but large excesses signal a qualitatively different action from what was authorized. The ESCALATE tier implements "meaningful human oversight" as required by EU AI Act Article 14 — with actual quantitative evidence, not just a kill switch.

Mandate Laundering: The Attack You Didn't Know Existed

Here's the attack that no existing security framework addresses: mandate laundering.

In a delegation chain Human → Agent₁ → Agent₂ → ... → Agentₖ, each intermediate agent can marginally expand the mandate it passes on. Each local expansion looks proportionate. But the cumulative expansion is not.

COA-MAS anchors the Justification Gap to the root human mandate, regardless of intermediate expansions:

G_chain(Aₖ) = Gⱼ(V_{Aₖ}, V_{M₀})  ← root mandate, always

G_total = 0.30 · G_local + 0.70 · G_chain

Non-Improvement Theorem: For any permissive subdelegation, G_chain is monotone non-decreasing. You cannot launder your way out of the original constraint.

How COA-MAS Fits the Standards Ecosystem

COA-MAS doesn't compete with existing standards — it implements what they defer:

Initiative	What It Solves	What It Defers	COA-MAS Role
IETF draft-klrc-aiagent-auth	Identity, authentication, authorization (SPIFFE, OAuth 2.0)	Policy model explicitly out of scope	Implements the policy model
A2A Protocol v1.0	Agent coordination standard	Authorization at execution boundary	AASG is the enforcement point A2A lacks
MCP v1.0	Agent-to-tool communication	No semantic authorization layer	AASG is the authorization gate MCP doesn't have

The IETF draft's Section 12 explicitly states: "the policy model and document format are out of scope." That is precisely where COA-MAS contributes.

The Failure Mode Transition

The most consequential architectural property of COA-MAS is the failure mode it introduces.

Traditional agentic systems: fail semantically and silently. The agent reinterprets a guideline, slightly expands a scope, finds an unanticipated interpretation. Detectable only after damage, through log analysis.

COA-MAS: introduces the explicit CONGRUENCE_VIOLATION failure mode. When an agent attempts an action that violates its declared impact vector, the AASG returns:

A specific error code
The dimension violated
The quantitative delta
A Merkle Ledger entry with full context

This is the organizational equivalent of a building inspector catching a code violation before the foundation is poured — not after the building collapses.

What's Published

The full paper, COA-MAS: A Governance Framework for Autonomous Agents in Production Environments, is available on Zenodo:

📄 zenodo.org/records/19057202

🔑 DOI: doi.org/10.5281/zenodo.19057202

📜 License: CC BY 4.0

The paper covers:

Full formal specification of the Action Claim ontology
Complete mathematical treatment of the Justification Gap
Attack pattern neutralization (scope subdeclaration, decomposition attack, mandate laundering)
EU AI Act regulatory alignment (Articles 9, 11, 13, 14)
Positioning against IETF, A2A, MCP, and AIMS model

Final Thought

The governance of autonomous agents is not a new problem. Simon identified its theoretical roots in 1947. Ostrom identified the institutional design solutions in 1990. Normative MAS researchers formalized the computational analogues through the 1990s and 2000s.

What's new in 2026 is the urgency.

Agents that can delete production databases and execute financial transactions are being deployed without the governance infrastructure this body of knowledge prescribes.

COA-MAS applies established principles to a new domain. The question is not whether governance is necessary — it's whether we build it before or after the first major incident.

If you're building multi-agent systems in production, I'd be genuinely interested in feedback on whether these primitives map to the problems you're encountering. The paper is open access — feel free to cite, critique, or extend.

— Rudson Kiyoshi Souza Carvalho, Independent Researcher

doi.org/10.5281/zenodo.19057202

TERSE — A New Serialization Format Built for LLMs

Rudson Kiyoshi Souza Carvalho — Tue, 31 Mar 2026 12:10:36 +0000

JSON is the default. But defaults were built for a different world.

Every time you send structured data to a Large Language Model, you pay for it token by token. And if you're using JSON — which almost everyone is — you're paying for a lot of characters that carry no information.

Take this simple payload:

{
  "user_id": 1001,
  "status": "active",
  "data": ["feature_a", "feature_b"],
  "verified": true
}

Count the noise: braces, quotes around every key and string value, commas, colons with spaces. Now imagine this multiplied across thousands of API calls per day. That's real money.

I built TERSE to address this.

What is TERSE?

TERSE (Token-Efficient Recursive Serialization Encoding) is a text-based data serialization format designed to represent the complete JSON data model with substantially fewer tokens — making it significantly more cost-efficient for use as input to Large Language Models.

The same payload in TERSE:

user_id: 1001
status: active
data: [feature_a feature_b]
verified: T

Same information. ~47% fewer tokens.

How it compares

Format	Token savings vs JSON	Full JSON coverage?
JSON	baseline	✓
YAML	~20%	✓ (verbose arrays)
TOON	~40%	✗ (flat data only)
TERSE	~47%	✓

YAML is a genuine improvement over JSON — it's more compact and covers the full data model. But it was designed for humans to write, not for LLMs to consume. Verbose arrays (- item per line), full-word booleans (true/false), and a notoriously complex parser spec limit its token savings.

TOON goes further on token reduction but falls apart with nested objects — it only works for flat, uniform tabular data. If your payload has any nesting, TOON can't represent it.

TERSE was designed to close that gap: full JSON data model coverage, with token efficiency as the primary design constraint.

The five design principles

1. Bare strings — identifiers and common values require no quotation marks. production stays production, not "production". Quotes are reserved for strings that actually need them — those containing spaces, reserved characters, or special syntax.

2. Compact primitives — null, true, and false become single characters: ~, T, F. Three of the most common values in any payload, each reduced to one token.

3. Implicit delimiters — spaces separate values inside objects and arrays. No trailing commas, no colons between array elements.

4. Schema arrays — the biggest token win for tabular data. Uniform arrays of objects declare their fields once, then list values positionally:

users:
  #[id name role active]
  1 Alice admin T
  2 Bruno editor T
  3 Carla viewer F

The equivalent JSON repeats "id", "name", "role", "active" on every single row. For a 100-row dataset, that's 400 unnecessary key repetitions.

5. Recursive structure — all constructs nest arbitrarily. Objects inside arrays inside schema arrays — all valid, all compact. No flat-only limitations.

A real example: nested order

JSON (~180 tokens):

{
  "orderId": "ORD-001",
  "customer": {
    "name": "Rafael Torres",
    "email": "r@email.com"
  },
  "items": [
    {"sku": "A1", "qty": 2, "price": 9.99},
    {"sku": "B3", "qty": 1, "price": 24.50}
  ],
  "paid": true,
  "notes": null
}

TERSE (~95 tokens):

orderId: ORD-001
customer: {name:"Rafael Torres" email:r@email.com}
items:
  #[sku qty price]
  A1 2 9.99
  B3 1 24.50
paid: T
notes: ~

This is where TERSE separates itself from TOON and CSV — deeply nested structures work exactly as expected.

You don't write TERSE by hand

The workflow is identical to JSON:

Your data (object/dict)
      ↓
serialize()        ← terse-js or terse-py
      ↓
TERSE string       ← sent to the LLM
      ↓
parse()            ← if you need it back
      ↓
Your data again

Just like nobody writes JSON.stringify() output by hand — you call the function. TERSE works the same way. The format is optimized for the one reader that actually matters: the LLM.

On design intent: why not compress further?

TERSE could go deeper — automatic key abbreviation, binary type encoding, dictionary compression. We deliberately stopped short of that.

The goal is a format that remains human-auditable: you can open a .terse file in any text editor and understand what you're looking at without tooling. In LLM pipelines, auditability is a safety property, not just a convenience. When an agent misbehaves, you need to inspect its inputs.

Two questions that come up

Can I use TERSE for REST API communication between microservices?

You can, but it's not the primary use case. REST APIs are consumed by many clients across different teams and languages — JSON's universal support is a real advantage there. TERSE shines where you control both ends: serializing data before sending it to an LLM, and parsing the response on the other side.

Can I use TERSE for application configuration, like YAML?

Yes — the format supports everything YAML does for config files: nested objects, arrays, typed values, comments. Worth considering if your config is also consumed by an LLM as context.

What's available today

The project includes:

Formal specification (v0.7) with ABNF grammar, conformance rules, and security considerations — published on Zenodo with DOI: 10.5281/zenodo.19058364
Reference implementations in TypeScript, Python, Java, and Go
Live playground where you can paste JSON and see the TERSE output in real time

Everything is open source under MIT (implementations) and CC BY 4.0 (specification).

Resilience Evaluation and Optimization Framework — REOF

Rudson Kiyoshi Souza Carvalho — Wed, 12 Jun 2024 12:23:30 +0000

Autor: Rudson Kiyoshi Souza Carvalho

Data: Abril de 2024

Objetivo: Este documento apresenta o REOF, um framework para avaliar, quantificar e otimizar a resiliência e confiabilidade de sistemas, com foco em aplicações de software.

Ao avaliar sistematicamente cada componente crítico, a metodologia ajuda a identificar proativamente áreas de vulnerabilidade que podem comprometer a confiabilidade/resiliência do sistema.

1. Introdução ao REOF:

O REOF é uma ferramenta padronizada que permite a análise, quantificação e expressão da resiliência e confiabilidade de um sistema através de um índice numérico (IRC - Índice de Resiliência e Confiabilidade).
A metodologia foca na prevenção de falhas e na implementação de melhores práticas para aumentar a confiabilidade.

2. Metodologia de Análise REOF:

O método considera Verticais de Avaliação: O REOF divide a análise em "verticais" que representam pontos críticos de um sistema, como:

EE - Entrada Externa (pontos de interação com o cliente)
SE - Saídas Externas (envio de dados para outros sistemas)
CE - Consultas Externas (integrações com outros sistemas)
DI - Dados Internos (consultas a banco de dados, cache, etc.)
AC - Aplicação em Container (configurações de health check)
SEC - Framework de Segurança Habilitado (ex: Spring Security)

Um dos pontos mais importantes sobre este framework é que ele foi concebido para ser flexível a qualquer vertical criada, portanto, você pode criar suas próprias verticais de avaliação e poderá avaliar qualquer processo que tenha um conjunto de boas práticas a serem avaliados. (logo poderia avaliar verticais de infraestrutura, técnicas de construções de aplicativos mobile, entre outros processos.

Proteções e Pesos: Para cada vertical, são definidas "proteções" (melhores práticas) que aumentam a resiliência, cada uma com um peso específico.
"Com sua equipe de engenharia ou arquitetura, você poderá listar as melhores práticas de proteção para promover resiliência e confiabilidade ao sistema, definindo pesos para cada proteção aplicada."

Cálculo do Índice: O IRC é calculado pela soma ponderada das pontuações de cada vertical.

Fator de Degradação: Um fator de degradação é aplicado para considerar o impacto de múltiplos domínios/funcionalidades em um mesmo microsserviço (micromonolitos).

Para cada domínio adicional, quero reduzir a qualidade do índice geral em 10% para cada domínio/funcionalidade adicionada, pois incluir novas/extras funcionalidades/domínios diferentes faz com que seu serviço tenha que compartilhar recursos, e uma lentidão em uma funcionalidade pode esgotar recursos para outras funcionalidades no mesmo microsserviço.

Normalização do Índice: O IRC é normalizado para uma escala de 0 a 10, facilitando a comunicação e comparação entre diferentes sistemas.

3. IRC/REOF como SLA:

O REOF permite expressar o IRC em níveis de serviço (SLA):

item 1 Excelente (8 a 10)
item 2 Bom (5 a 7.9)
item 3 Aceitável (3 a 4.9)
item 4 Insatisfatório (abaixo de 3)

Pirâmide de confiabilidade REOF de Ruds

SLA para Serviço Excelente: O IRC/REOF deve ser maior ou igual a 8, indicando um nível de serviço excelente. Isso reflete a alta confiabilidade e eficiência do microserviço, sem sobrecarga de domínios adicionais.

SLA para Serviço Bom: O IRC/REOF deve ser entre 5 e 7.9, indicando um nível de serviço bom. Isso reflete a confiabilidade do microserviço.

SLA para Serviço Aceitável: O IRC/REOF deve ser entre 3 e 4.9, indicando um nível de serviço aceitável. Isso indica que há espaço para melhoria. Medidas corretivas devem ser aplicadas para aumentar a confiabilidade deste serviço e reduzir impactos de paradas do serviço por causa da aplicação.

SLA para Serviço Insatisfatório: O IRC/REOF deve estar abaixo de 3, indicando um nível de serviço insatisfatório. Isso indica que este serviço precisa de revisões e melhorias, não sendo um serviço confiável.

4. Flexibilidade e Automação:

O REOF é flexível e pode ser personalizado com novas verticais e proteções.
É possível automatizar o cálculo do IRC através de análise estática de código, mas a precisão pode ser limitada.

5. REOF vs. MTBF:

O REOF é uma medida proativa que avalia a robustez do sistema com base em sua construção, enquanto o MTBF é uma medida reativa que considera apenas o tempo médio entre falhas.

O MTBF é a métrica da sorte ao longo do tempo, um MTBF alto pode indicar que um sistema teve um bom histórico operacional, dadas as condições ideais de operação ambiental desse sistema, no entanto, não diferencia necessariamente sistemas genuinamente bem projetados daqueles que Você pode ter tido 'sorte' de ter um ambiente estável durante o período de execução e avaliação.

O REOF é mais abrangente e fornece insights mais acionáveis para melhorar a resiliência.

6. Relação com Chaos Engineering:

REOF e Chaos Engineering são abordagens complementares.
O REOF garante que as melhores práticas de resiliência sejam aplicadas durante o desenvolvimento, enquanto o Chaos Engineering testa a resiliência do sistema em produção.

7. Benefícios do REOF:

Comunicação eficaz sobre a confiabilidade do sistema.
Identificação precisa de áreas de melhoria.
Cultura de melhoria contínua e prevenção de falhas.
Gerenciamento de riscos e conformidade com SLAs.
Melhor experiência do usuário.

8. Considerações sobre Custos:

Implementação do REOF pode ter custo inicial significativo, mas reduz custos operacionais a longo prazo.
Chaos Engineering pode ter baixo custo de implementação, mas custos operacionais podem ser altos durante os testes.

Como o método REOF é melhor do que o método MTBF?

O MTBF é uma estatística de funcionamento do seu sistema, segundo um histórico operacional, uma medição ao longo do tempo, onde um sistema pode funcionar muito bem dada as condições ideais de operação, se nada de anormal acontecer no seu ambiente/infra, o MTBF indicará que seu sistema é extremamente confiável, pois ele depende das condições sob a qual o seu sistema opera para que possam ocorrer falhas, este método não sabe como seu sistema foi construído, considera a freqüência de falhas num período de tempo, e não a robustez como o sistema foi construído para lidar com diferentes tipos de variações no ambiente e consequentemente se proteger das falhas, é um método reativo.

O MTBF é a métrica da sorte em função do tempo, um MTBF alto pode indicar que um sistema teve um bom histórico de funcionamento dada as condições de ambiente ideais de operação deste sistema, porém, não necessariamente distingue entre sistemas genuinamente bem projetados e aqueles que pode ter tido "sorte" de ter um ambiente estável durante o período de execução e avaliação.

O REOF genuinamente avalia a robustez do sistema, como o sistema foi construído para lidar com os diferentes tipos de problemas que possam ocorrer no ambiente produtivo, é um método proativo.

Relação entre o método REOF e o Chaos Monkey/Engineering

O método REOF, contrasta com a aplicação de ferramentas como o Chaos Monkey em vários aspectos fundamentais. Ambas as abordagens visam melhorar a resiliência e a confiabilidade dos sistemas, mas fazem isso de maneiras complementares, a engenharia do caos é uma disciplina de experimentação em um sistema para criar confiança na capacidade do sistema de resistir a condições turbulentas na produção, enquanto este método garante que foram aplicadas as melhores práticas para resistir ao caos, ou seja, garante a preparação para falhas, os pontos fortes da metodologia de avaliação de confiabilidade em relação ao uso de um Chaos Monkey são:

Foco na Prevenção e Melhoria Contínua

Avaliação Holística: A metodologia fornece uma visão abrangente da performance do sistema ao longo do tempo, permitindo identificar tendências, áreas de melhoria e impactos das mudanças, ao contrário do Chaos Monkey, que testa a resiliência de forma mais imediata e isolada.

Incentivo à Inovação: A gamificação incentiva (proposta tópico desafio de excelência) as equipes a buscar melhorias contínuas e soluções inovadoras para elevar os índices de confiabilidade, promovendo uma cultura de excelência operacional.

Planejamento Estratégico: Oferece uma base para o planejamento estratégico e a alocação de recursos, ao identificar áreas críticas que necessitam de atenção e investimento, algo que a aplicação isolada do Chaos Monkey não proporciona diretamente.

Gestão de Riscos e Conformidade

Redução de Riscos Operacionais: Ao focar na avaliação e melhoria contínuas da confiabilidade, esta metodologia ajuda a mitigar riscos operacionais de longo prazo, enquanto o Chaos Monkey é mais uma ferramenta de teste de estresse que expõe vulnerabilidades.

Conformidade com SLAs: A metodologia permite a monitoração proativa e a garantia de que os serviços atendam ou excedam os SLAs acordados, o que é fundamental para a satisfação do cliente e a conformidade regulatória.

Melhoria da Experiência do Usuário

Foco no Usuário: Avaliar e melhorar a confiabilidade com base nos SLAs enfatiza a importância da experiência do usuário, visando garantir uma operação sem interrupções e desempenho otimizado dos serviços.

Antecipação de Problemas: Permite a identificação e correção proativa de possíveis falhas antes que afetem os usuários finais, enquanto o Chaos Monkey simula falhas para testar a resiliência, o que pode ou não ser diretamente relacionado à experiência do usuário.

Complementaridade com Ferramentas de Teste de Resiliência
Abordagem Integrada: Embora focada em avaliação e melhoria, essa metodologia pode ser complementada por ferramentas como o Chaos Monkey para uma abordagem mais robusta à resiliência. Juntas, elas oferecem uma estratégia de defesa em profundidade contra falhas e interrupções.

Em resumo, a metodologia de avaliação de confiabilidade traz uma abordagem preventiva e estratégica para a gestão da confiabilidade dos sistemas, enfocando a melhoria contínua, a inovação e a satisfação do cliente. Enquanto o Chaos Monkey é uma ferramenta valiosa para testar a resiliência de forma específica e isolada, a combinação das duas abordagens oferece um caminho poderoso para alcançar a excelência operacional e a resiliência do sistema.

Conclusão:

O REOF é um framework poderoso para construir e gerenciar sistemas resilientes. Sua abordagem proativa, foco na prevenção e flexibilidade o tornam uma ferramenta valiosa para qualquer organização que busca alcançar a excelência operacional e garantir a satisfação do cliente.

Siga o link para mais detalhes:
Follow the medium link for more details about this framework: Medium REOF

DEV Community: Rudson Kiyoshi Souza Carvalho

TERSE Tool Catalog (TTC): Cut Tool Catalog Token Usage by 66.6% in Your AI Agents

The Problem with Today’s MCP JSON Schema

Introducing the TERSE Tool Catalog (TTC)

TTC Syntax — Clean and Simple

Supported Types

Real-World Example: gmail_send_email

Real Benchmark (10 Production Tools)

Why TTC Works So Well

How to Use It in Your Agent Context

Reference Converter (Python)

Planned Future Extensions

Conclusion

Links

Your AI agent wastes 13,000 tokens before saying "hello"

"But there's prompt caching, right?"

The real problem nobody talks about

TTC — TERSE Tool Catalog

It's not compression. It's reallocation.

Real benchmark — 10 measured tools

Normative WHEN vocabulary

Where it works best

Links

Seu agente de IA está desperdiçando 13.000 tokens antes de dizer "oi"

"Mas tem prompt caching, não?"

O problema real que ninguém fala

TTC — TERSE Tool Catalog

Não é compressão. É realocação.

Benchmark real — 10 tools medidas

Vocabulário normativo para WHEN

Onde funciona melhor

Links

COA-MAS v2: A Meta-Framework for Cross-Domain Multi-Agent Governance

The Silver Bullet Fallacy

The Thesis

The Action Intent

The Four Federation Modes

The Pattern Selection Protocol

Positioning Against CAGA

What's Published

AI Agents Can Delete Your Production Database. Here's the Governance Framework That Stops Them.

The Problem No One Is Talking About

The Structural Failure Mode: Distributed Cognitive Chaos

COA-MAS: A Governance Framework Grounded in Theory

Component 1: The Four-Layer Architecture

Component 2: The Action Claim

Component 3: The AASG (Autonomous Agent Security Gateway)

What happens when an agent lies?

The Justification Gap: The First Computable Proportionality Metric

Mandate Laundering: The Attack You Didn't Know Existed

How COA-MAS Fits the Standards Ecosystem

The Failure Mode Transition

What's Published

Final Thought

TERSE — A New Serialization Format Built for LLMs

What is TERSE?

How it compares

The five design principles

A real example: nested order

You don't write TERSE by hand

On design intent: why not compress further?

Two questions that come up

What's available today

Links

Resilience Evaluation and Optimization Framework — REOF

Real-World Example: `gmail_send_email`