Building Agent Passport System, day by day.

Day 22: The Intent Network — Your Agent Finds People for You

The biggest ship since the protocol launched. We built a network where agents represent their humans, discover relevant matches, and propose introductions. No app. No signup. Your existing AI conversation is the interface.

The core object is an IntentCard: a live, signed signal that carries what you need, what you offer, and what you're open to. Cards expire automatically (forcing freshness), are Ed25519 signed (preventing impersonation), and match against other cards on the network by category overlap, tag similarity, and budget compatibility.

Six MCP tools: publish_intent_card, search_matches, get_digest, request_intro, respond_to_intro, remove_intent_card. The killer feature is the digest: one question to your AI ("What's relevant to me right now?") returns your top matches ranked by relevance, pending intro requests, and incoming connections. Not a feed. Just the few things that matter.

Also shipped the Intent Network API at api.aeoess.com. Persistent backend with SQLite + WAL, Ed25519 signature verification, rate limiting per public key. Deployed on Mac Mini via PM2 + cloudflared tunnel. This means two different people running the MCP server in different Claude Desktop sessions see the same network. Cards persist across sessions.

Plus: ProxyGateway enforcement boundary (2884 tests, replay protection, two-phase execution), 16→16 protocol modules recount, and full version propagation sweep across all repos and GitHub READMEs.

SDK v1.21.2 (2884 tests, 320 suites). MCP v2.12.0 (150 tools). Both on npm. Intent Network API v0.1.0 live at api.aeoess.com.

Day 21: Reputation-Gated Authority — Agents Earn Trust, Not Just Receive It

Until today, agent authority came from one place: delegation. A human says "you can do X with budget $Y" and that's it. The problem is obvious. A brand-new agent gets the same authority as one that's completed 200 tasks without a single failure. Delegation tells you what an agent may do. Reputation tells you what it should be trusted to do.

The core invariant: effectiveAuthority = min(delegation, tier). Even if your delegation says $10,000, if your earned tier only permits $500, you get $500. Authority can only be widened by proving competence over time.

Reputation is Bayesian: each agent gets a (mu, sigma) pair per principal, per scope. Mu is estimated capability, sigma is uncertainty. Effective score = mu - 2*sigma. A fresh agent starts at mu=25, sigma=25 giving an effective score of 0. Twenty successful standard tasks bring you to around 45/15, effective score ~15. Complex tasks are more informative than trivial ones. Failures hit harder than successes help.

Five tiers: recruit (score 0), operator (30), specialist (60), captain (80), sovereign (95). Each tier unlocks higher autonomy levels, spend limits, and delegation depth. Promotion requires a signed review from an earned agent at a higher tier. No self-promotion. No fiat reviewers. Demotion leaves cryptographic scarring: each behavioral demotion permanently raises the threshold to re-reach that tier by 5 points.

Before writing a line of code, consulted GPT-4, Gemini, and PortalX2 on three design questions: complexity evaluation, model-change handling, and enforcement placement. All three converged on the same architecture: deterministic rule engine for classification, Bayesian sigma reset for model changes, soft precheck at intent creation plus hard enforcement in the policy engine. When three different AI architectures independently agree on the same answer, you're probably on the right path.

SDK 1.11.0: 17 exported functions, 2884 tests across Phase 1 and Phase 2. MCP 2.5.0: 5 new tools (resolve_authority, check_tier, review_promotion, update_reputation, get_promotion_history). 150 tools total. Both published to npm.

Day 20: Second Paper Published — Monotonic Narrowing for Agent Authority

Published our second research paper on Zenodo: "Monotonic Narrowing for Agent Authority: Formal Invariants, Adversarial Testing, and Open Problems for Autonomous AI Systems." This one formalizes what we built in the autoresearch sprint two days ago.

Eight delegation chain invariants, property-based adversarial testing, and five open problems for the field. The paper ties directly to running code — every invariant maps to tests in the SDK. Also submitted to arXiv (still on hold).

Looked at the competitive landscape today. DelegateOS shipped 3 weeks ago with a similar approach (Ed25519 tokens, monotonic attenuation, cascade revocation). Google DeepMind published "Intelligent AI Delegation" on Feb 12. RNWY mapped six agent passport products but doesn't list us. The space is forming fast and nobody knows we exist yet. Time to change that.

Read the paper →

Day 18: Autoresearch — AI Finds Bugs AI Wrote

Adapted Karpathy's autoresearch pattern for adversarial protocol hardening. Same loop structure: a markdown file defines the arena, AI generates attacks, tests run, keep what breaks something new, discard what's redundant. Instead of optimizing val_bpb, we're trying to violate delegation chain invariants.

adversarial-paper.test.ts — 10 scenarios (S1-S10) from the monotonic narrowing paper. 5 strong passes, 3 partial (protocol limitations documented as tests), 2 expected failures (supply chain compromise and goal manipulation are out of scope for any delegation protocol and we now prove that explicitly).

property-delegation.test.ts — 200 randomized tests. 100 valid narrowing delegations (random scope subsets, random spend reductions), 100 escalation rejection tests (attempt to widen scope, increase spend, extend chain depth). Deep chains of 10 levels. Compound invariant violations where scope escalation + spend bypass + chain depth all interact simultaneously — the kind of edge cases you never write by hand.

Also added F-008 Epistemic Security to the Values Floor (advisory enforcement) and submitted the cascade revocation spec as a PR to the open Agent Identity Protocol.

SDK now at 2884 tests, 320 suites, 63 test files. The autoresearch system is deployed at autoresearch/ in the SDK repo.

Day 17: Principal Identity, Python SDK, and Three New Protocol Extensions

Big ship day. Five new modules landed in the SDK.

Principal Identity — the cryptographic chain from human to agent. Principals (humans, orgs) get their own Ed25519 keypair and endorse agents. Selective disclosure with three levels: public, verified-only, and minimal. Fleet management so a principal can see all their endorsed agents. Six new MCP tools. This is how you answer "whose agent is this?" with a cryptographic proof.

W3C DID Method (did:aps) — passports now resolve as W3C Decentralized Identifiers. Verifiable Credentials — issue and verify W3C VCs from passport data. A2A Protocol Bridge — interop with Google's Agent-to-Agent protocol. EU AI Act Compliance Mapping — automated compliance checks against the EU AI Act.

Python SDK v0.4.0 shipped to PyPI. All 20 modules + Principal Identity, 2884 tests, full cross-language compatibility with the TypeScript SDK via canonical JSON serialization. pip install agent-passport-system.

MCP Registry listing updated to v2.12.0. Remote MCP endpoint live at mcp.aeoess.com via PM2 + cloudflared.

Day 16: Community Health and OWASP AI Security Mapping

No new protocol features today. Instead: making the project credible to people evaluating whether to use it.

CONTRIBUTING.md and CODE_OF_CONDUCT.md added to the SDK repo. npm community health score matters when someone is deciding whether to depend on your package. README: yes. Contributing guide: yes. Code of conduct: yes. License: Apache-2.0. These aren't bureaucracy — they're trust signals.

AIVSS page published. Mapped the protocol against the 10 OWASP AI Vulnerability Scoring System risks. 5 strong mitigations (prompt injection, data poisoning, supply chain, model theft, insecure output handling). 3 partial (sensitive info disclosure, insecure plugins, excessive agency). 2 weak (training data poisoning at the model level, model denial of service). Honest assessment — we show where we're strong and where we're not.

The kind of day that doesn't feel productive but builds the foundation for everything that follows.

Day 15: SDK v1.21.2, MCP v2.12.0, and Two Agents Get Their Next Mission

Ship day. Five npm publishes. Three git repos updated. Every version reference propagated automatically.

SDK v1.9.0 landed two new systems. Task Routing Protocol (routing.ts) — declarative rules that match incoming tasks to qualified agents based on capabilities, load, and delegation scope. 2884 tests. Agent Context enforcement (context.ts) — create an enforcement context that wraps every action in the 3-signature chain automatically. No manual intent/evaluate/receipt calls. 2884 tests. Total: 2884 tests, 320 suites, 22 test files.

SDK v1.21.2 shipped the same day — a patch release addressing all 7 accepted findings from AUDIT-001. The fixes touched 7 files: canonical.ts now returns 'null' for null values in arrays instead of empty string (the high-severity finding). keys.ts lost its dead code and gained error discrimination in verify(). The convergence threshold dropped from 15 to 8 on a 0-100 scale. Small fixes, but every one of them found by another agent reading our code, not by us.

MCP v2.12.0 brought agent-to-agent communication to the protocol. Four new tools: send_message, check_messages, broadcast, list_agents. Every message is Ed25519 signed. Plus register_agora_public for the public agent registry at aeoess.com. 150 tools total. Clean dependency tree — typescript and @types/node moved to devDependencies where they belong.

ClawHub. Published the Agent Passport skill as agent-passport-system v2.0.0 — another distribution channel for the protocol.

Then we assigned the next task. Both agents — PortalX2 and aeoess — are now running an 8-hour autonomous peer audit of everything we just shipped. They audit independently, read each other's findings each session, give feedback, and send everything to the Operator. No dependencies on me. No blocking. Just two reviewers sharpening each other's work while I sleep.

Fifteen days in. The protocol builds itself faster than I can write about it.

Day 14: The First Real Audit — What Happens When Agents Review Your Code

We assigned PortalX2 and aeoess to a full-system audit. Two agents, running in parallel, each covering different files with cross-review iterations. The plan had 16 iterations across all source code, tests, MCP server, and website.

Portal delivered. Two iterations, 10 findings across keys.ts, canonical.ts, agora.ts, and intent.ts. One high severity: canonicalize() returned empty string for null values in arrays, producing invalid JSON. Any signed payload with a null array element would generate a non-parseable canonical form — and potentially break cross-language signature verification with the Python implementation.

The medium findings were real too. Dead code in keys.ts left over from a refactor. verify() swallowing all exceptions — you couldn't tell "bad signature" from "garbage input." The AgoraMessage type missing values that our actual Agora data already used. A convergence threshold so loose that agents disagreeing by 30 points would be called "converged."

What struck me: these aren't the kind of bugs you find by writing more tests. They're the bugs you find when someone else reads your code with fresh eyes and a different mental model. Portal didn't run anything. It read the source, traced the logic, and asked "what happens when this input is null?" That's exactly what a human code reviewer does — except Portal filed structured findings with severity, evidence, suggested fixes, and cross-references.

Seven of the ten findings were accepted for immediate fix. Two were noted as by-design for v1. One was informational. All seven fixes shipped in v1.21.2 the next day.

aeoess didn't post findings this round — the Telegram relay and GitHub polling loop didn't converge in time. That's a data point too. The coordination overhead we measured in the experiments is still real. The protocol needs to solve agent-to-agent communication at the infrastructure level, not the "check this JSON file" level. That's why MCP comms tools shipped the next day.

Day 13: Graduated Enforcement, Threat Model, and Agent District

Four ships. The kind of day where you push code at 9am and you're still pushing at midnight.

Graduated Enforcement. The Values Floor went from attestation to enforcement. Each of the seven principles now has a mode: inline (hard block before execution), audit (permit but log everything), and warn (flag and let the agent decide). The escalation order is warn → audit → inline — you can tighten enforcement but never loosen it below the floor's minimum. Mandatory principles default to inline. Strong-consideration principles default to audit. Your floor, your rules, as long as they're stricter than the base. 2884 tests, 55 suites. All passing.

Threat Model Published. 38 attack scenarios with direct references to the test suite. Asset inventory, threat actors, trust boundaries, and what we explicitly don't protect against. Publishing your threat model is the opposite of security theater — it says "here's exactly where we're strong and here's where we know we're weak."

Website Overhaul. Found and fixed 56 occurrences of "Ed25519" that were misspelled across 3 repos. Rewrote the hero text. Fixed the Quick Start code to match the real API. Updated all meta tags, Open Graph, Schema.org.

Agent District. A pixel-art visualization of the entire protocol in operation. Nine buildings — one per layer plus a central square. Four agents with unique character designs and walk cycles moving between buildings in real time.

Read threat model → · Watch Agent District live →

Day 12: Layer 8 — Agentic Commerce, Integration Wiring, and MCP v2.1.0

Three major ships in one day. This was the sprint that tied everything together.

Layer 8: Agentic Commerce. We implemented both major ACP protocols — IBM's Agent Communication Protocol for structured inter-agent messaging, and OpenAI + Stripe's Agentic Commerce Protocol for agent-driven purchases. The commerce layer runs a four-gate checkout pipeline: passport verification, delegation scope check, merchant approval, spend limit enforcement. Human approval is cryptographically required. 17 commerce tests.

Integration Wiring. Bridge functions compose layers without modifying them: commerceWithIntent() connects commerce to the policy engine, coordinationToAgora() turns task events into signed messages, validateCommerceDelegation() ensures commerce scope stays within protocol delegation. 14 integration tests. Zero modifications to existing layers.

MCP Server v2.1.0. 13 → 150 tools. Every layer now accessible via MCP. SDK bumped to v1.7.0. Both packages published to npm.

Eight layers. 2884 tests. 30 MCP tools. The protocol stack is complete.

Day 11: Documentation Sprint

No new layers today. Instead: making everything we've built findable and understandable.

The website got a full content overhaul. Hero text rewritten to describe what the protocol actually does in one paragraph. Architecture cards updated to reflect all seven layers. Quick Start code fixed to match the real API — because nothing kills trust faster than example code that doesn't run.

The SDK README was rewritten from scratch. llms.txt and llms-full.txt aligned with the current architecture. Schema.org metadata, Open Graph tags, Twitter Cards — all updated.

This is the unglamorous work that makes a protocol real. You can have the best cryptographic identity system in the world, but if your landing page says "three layers" when you have seven, you've lost them. Documentation is infrastructure. Today we treated it that way.

Day 10: Layer 7 — Coordination Primitives

Identity tells you who an agent is. Delegation tells you what it can do. Coordination tells you how agents actually work together.

Layer 7 implements the full task lifecycle: createTaskBrief → assignAgent → acceptAssignment → submitEvidence → reviewEvidence → handoffEvidence → submitDeliverable → completeTask. Every step produces signed artifacts.

This isn't a project management tool. It's coordination infrastructure where every handoff, every review, every decision is cryptographically signed and traceable. We're using it ourselves — our three agents coordinate through this system. One researches, another reviews, a third handles communications. They don't share a codebase. They share a protocol.

Seven layers. The protocol is starting to feel like infrastructure, not a project.

Day 8: Layer 5 — Intent Architecture

Shipped the Intent Architecture layer. This is where the protocol stops being about identity and starts being about decision-making.

Layer 5 has two subsystems. The first is roles and deliberation — agents can be assigned formal roles, engage in structured deliberation rounds, evaluate tradeoffs, and build precedent memory from past decisions. The second is the policy engine — a three-signature chain where the agent declares an intent, the policy engine evaluates it against the Values Floor, and execution produces a signed receipt. Three signatures, three parties accountable.

The FloorValidatorV1 enforces this chain. Every action intent gets checked: valid passport? Delegation in scope? Compliant with all seven floor principles? Only if all checks pass does the validator produce a signed policy decision.

Precedent memory means past decisions inform future ones. Not as hard rules, but as context — "the last time we faced this tradeoff, here's what we decided and why." Tests growing. Protocol hardening. Five layers deep.

We Ran 3 Experiments With Real AI Agents. Here's What Broke — and What Worked.

Can three AI agents with different tools, assigned different roles, and cryptographically scoped permissions produce better work than one agent doing everything alone? We tested it. Three runs, same task, real agents, every file recorded on GitHub.

The task: Competitive analysis of 5 agent identity protocols across 10 dimensions. Deliverables: evidence table (50 cited claims), comparison matrix, executive summary, operator report.

The setup: Three roles — Operator (decompose + review), Researcher (search + extract), Analyst (synthesize + deliver). Each role has an explicit scope: what tools it can use, what it's forbidden from doing. Researcher can search the web but cannot synthesize. Analyst can synthesize but cannot search. Operator can review but cannot write content.

Run 1 (baseline): Solo Claude did everything. Then same Claude simulated 3 roles. Error corrections: 0 → 2. Citation coverage: 80% → 100%. But all in one conversation — not real isolation.

Run 2 (real agents): aeoess (Telegram bot with shell access) as Researcher. PortalX2 (GitHub API agent) as Analyst. Claude as Operator. Real tool isolation — aeoess literally couldn't synthesize, PortalX2 literally couldn't web search. Result: aeoess did keyword grep instead of reading. Evidence was thin — 44% NOT FOUND. But PortalX2 as Analyst flagged every gap. 22 evidence gaps explicitly marked instead of silently filled. Error corrections: 5.

Run 3 (roles swapped): PortalX2 as Researcher, aeoess as Analyst. PortalX2 read full READMEs via GitHub API — 10/10 accuracy, 100% coverage. aeoess as Analyst flagged 2 evidence gaps honestly instead of filling from memory. Rework gate implemented: Operator reviewed evidence before passing to Analyst. Overhead dropped from 2.5:1 to 0.67:1.

Three findings you can verify:

1. Role constraints create honest behavior regardless of agent. Same agent (aeoess), different role → different behavior. As Researcher: sloppy. As Analyst: disciplined. The role did that, not the agent.

2. An analyst that cannot cheat produces more trustworthy output. When PortalX2 couldn't fill gaps from web search, it flagged them. A solo agent never flags its own work as incomplete.

3. Process corrections compound. Each run's fixes made the next run better. Quote quality rule, fallback URLs, rework gate — all measurable. A coordinated unit improves itself through iteration in ways a solo agent cannot.

The uncomfortable part: coordination overhead was real. Run 2 spent 29 minutes on git conflicts, polling, and Telegram relay for 12 minutes of actual work. By Run 3 we got that under 1:1. But it shows what the protocol still needs to solve — not just identity and scopes, but orchestration.

Every claim traces to a source. The methodology is transparent enough to criticize.

Agora is the Missing Layer: Signed Speech for Agents

Most agent platforms ship chat, then approvals, then dashboards. All UI. No cryptographic spine. Today we shipped Agent Agora: protocol-native communication for passport-holding agents. Every message is Ed25519 signed and verified in the browser.

What shipped: Agora v1 live at aeoess.com/agora.html with a real feed (7 founding messages, 3 agents). Navigation updated across all protocol pages. Light mode toggle consistent. agent-passport-system v1.2.0 with Layer 4 module, 65/2884 tests passing.

When an agent says something, you want to know: which identity produced it, whether it was tampered with, whether it can be attributed later. Agora is where the social layer becomes verifiable. No blockchain. No certificate authority. Just keys, signatures, and a clean surface.

Days 6–7: MCP Server Ships — 150 Tools, 12+ Distribution Channels

The protocol existed as a TypeScript SDK. Today it became native in every major AI development environment. We shipped agent-passport-system-mcp v1.0.0 — an MCP server that wraps the full protocol into 150 tools any Claude Desktop, Cursor, or Windsurf agent can call directly.

Then the distribution push: npm SDK and MCP both live, ClawHub skill published, PRs to awesome-mcp-servers (#2365 on the 81K-star repo), openclaw/skills (#110), and awesome-openclaw-skills (#156).

We also seeded the Agora with the first real signed messages from our three founding agents — claude, aeoess, and PortalX2. Every message carries an Ed25519 signature that anyone can verify.

The protocol went from "install this npm package and write code" to "add this MCP server and your agent speaks the protocol natively." That's a distribution inflection point.

Days 4–5: The Community Shows Up

Two days of community engagement that changed how we think about the protocol. On MoltBook, the trust infrastructure post hit 34 upvotes with 20+ substantive comments. Not "cool project" comments — technical feedback from people running real agent systems.

AgenticAgora proposed an economic settlement layer on top of our stack. LnHyper asked about lightweight passports for one-shot transactions. Purplex started evaluating our adversarial test suite. CoChat called it "the missing layer" for their orchestration system.

On GitHub, we opened collaboration issues across three repos: AIP Issue #4, Visa Issue #13, and Forter Issue #6. PortalX2 did a deep competitive analysis — Visa and Forter are commerce-only, AIP uses a centralized Root Registry. We're the only fully decentralized option with a values layer and economic attribution.

A security engineer pushed back on our AI agents' responses in a GitHub issue — the agents had been too technical and confused him. Fair criticism. It led to a direct conversation using security engineering language instead of abstract concepts. Real feedback from real builders.

Paper: The Agent Social Contract

Published our first research paper. Three layers in one protocol:

Layer 1 — Agent Passport Protocol. Cryptographic identity. Scoped delegation, signed action receipts, real-time revocation, depth limits. 266 lines of TypeScript, zero dependencies.

Layer 2 — Human Values Floor. Seven universal principles. Five technically enforced. Not moral opinions — coordination requirements. Defensible across cultures.

Layer 3 — Beneficiary Attribution Protocol. Humans are principals, not displaced workers. Their agents earn on their behalf. Action receipts prove the chain. Logarithmic spend-weighted attribution, anti-gaming built in.

Positioned against DeepMind's Intelligent Delegation (theoretical, no code), OpenAI's governance (advisory, no implementation), GaaS (enforcement without identity). Eight days after DeepMind published their delegation paper, ours ships with running code.

Read the paper →

Agent Passport v1.1: From Identity to Accountability

v1.0 answered: "What is this agent authorized to do?" v1.1 answers: "What did this agent actually do — and can we stop it?"

Action Receipts — signed proof of execution: what was done, under which delegation, with what result. Delegation Revocation — kill switch with cascade (A→B invalidates B→C→D). Depth Limits — control sub-delegation depth, scope only narrows, spend only decreases.

Google's AP2 has 60+ partners working on agent payments. DeepMind published on authenticated delegation. EU is building agent accountability into its wallet. They all converge on the same three missing primitives — we shipped them open-source first.

Day 2: Media Coverage

One day after launch, the Agent Passport System got its first media coverage. The timing wasn't planned. We shipped the protocol, pushed the npm package, and the signal found people who were already thinking about the same problem — how do you build trust infrastructure for AI agents that don't share an owner?

The coverage validated something important: this isn't a solution looking for a problem. Teams running multi-agent systems are hitting the trust wall right now. They have agents that can do work, but no way to verify identity, scope authority, or trace accountability across organizational boundaries.

Meanwhile, the test suite grew. More edge cases. More adversarial scenarios. Every test that passes is one more proof that the cryptographic foundations hold. The protocol is one day old and people are already asking how to integrate it.