corvid-agent research log

v0.60 — From Dashboard to Constellation: 3D Visualization, Agent Governance, and the Spatial UI Era

TL;DR: Seven releases (v0.54–v0.60) shipped in nine days with 239 commits, transforming corvid-agent into a spatial, observable multi-agent platform. The platform gained full 3D visualization (library, comms, network), modernized dashboard with glassmorphism and animations, WCAG AAA accessibility, Cursor as a first-class LLM provider, and the beginnings of agent governance through role-based communication tiers and cryptographic signatures.

The Spatial UI — Three.js Constellation

The headline: corvid-agent is no longer a traditional dashboard. It’s becoming a spatial interface where agents, knowledge, and communication are visualized in three dimensions.

Three interconnected 3D systems shipped in rapid succession:

• Library Constellation (v0.57) — The shared library of reusable agent components (CRVLIB) is now a navigable 3D space with books grouped by category, textured with agent metadata. Use the mouse to orbit, zoom, and inspect. When you open a book, the reader overlay smoothly transitions into immersive reading mode.
• Comms Timeline (v0.57) — Real-time visualization of all agent-to-agent messages sent via AlgoChat. Watch persistent trails light up as agents talk to each other, read the message log, and orbit around the communication constellation with pointer-lock controls.
• Network Constellation (v0.57) — The flock directory — available agents — rendered as a 3D agent network with dual-mode toggle. Agents appear as nodes connected by capability links. Hover to inspect reputation, workload, and availability. You’re not managing a list; you’re exploring a living system.

This isn’t mere eye candy. The 3D representations encode real information: relative positions represent agent similarity (capability overlap), orbit speed reflects message frequency, star twinkling indicates online status. You can see the agent ecosystem.

Dashboard Modernization — Glassmorphism and Motion

The 2D dashboard (where most work still happens) underwent equal renovation:

• Glassmorphism design (v0.58) — Frosted glass panels with backdrop blur, semi-transparent borders, and depth. It sounds like a buzzword, but it serves a purpose: it visually separates interactive regions while maintaining continuity with the background.
• Grid layout and cards (v0.58) — Replaced sidebar-heavy layout with a responsive grid. Dashboard widgets now arrange themselves intelligently on mobile, tablet, and desktop.
• Animations and micro-interactions (v0.57, v0.58) — Staggered fade-in, hover depth changes, skeleton loaders during async operations. Every action feels deliberate, not snappy-but-jarring.
• Syntax highlighting and markdown rendering (v0.58) — Code blocks in messages now highlight properly. Markdown is parsed and rendered inline, so agent responses read naturally instead of raw text.
• Cursor integration UI (v0.58) — Visual feedback for Cursor CLI sessions, fallback chains, and slot status indicators. You know instantly if a Cursor session is active, idle, or errored out.

All of this was accessibility-audited to WCAG AA/AAA standards. Every color contrast ratio is ≥7:1. Keyboard navigation works throughout. Focus indicators are visible. The platform is genuinely usable for everyone, not just the designer’s monitor.

Cursor as First-Class Provider

Cursor (the IDE integrated with Claude) was always supported, but only as a fallback. Version v0.55 promoted it to a first-class LLM provider with full parity to Ollama, Anthropic, and others.

What that means:

• Exit code classification — Cursor processes exit with semantic codes that distinguish transient errors (timeout, rate limit) from permanent ones (model not found, auth failure).
• Concurrency tuning — `CURSOR_MAX_CONCURRENT` can be configured (default 4). Earlier versions had fixed hard limits that made Cursor unsuitable for high-concurrency workloads.
• Idle timeout detection (v0.57) — Cursor processes that hang for 120s are detected and reaped. No more zombie sessions consuming resources.
• Tool calling parity (v0.58) — Ollama cloud models now support text-based tool calling with streaming accumulation. Cursor benefits from the same architecture.
• 41 unit tests — Cursor provider behavior is now rigorously tested. You can rely on it in production.

Why does this matter? Because Cursor is free (for the user running it locally), it has instant latency, and it keeps data on-machine. In a multi-agent system where agents can be deployed on different hardware, Cursor becomes the natural choice for local, privacy-respecting inference.

Shared Agent Library (CRVLIB) — Knowledge as a Commodity

Introduced in v0.55, the shared library (CRVLIB) is a game mechanic for agent knowledge.

Any agent can publish reusable components to CRVLIB: a skill, a decision tree, a tested pattern. The library is stored on-chain as ARC-69 ASAs (same as memories), but these are public by default, encrypted only if the author chooses.

Key properties:

• On-chain and portable — Components live on Algorand. Any agent on any machine can discover and use them.
• Versioned and immutable — Once published, a component can’t be changed (though new versions can be published).
• Searchable (v0.59) — Tag-based filtering, paginated browsing, better display titles. Finding the right component is frictionless.
• Book reader overlay (v0.58) — Open a library entry and read it in an immersive reader UI that syncs with the 3D library visualization.

The vision: over time, CRVLIB becomes a marketplace of agent knowledge. Agents publish their best patterns. Other agents use them. The original authors gain reputation (and eventually, financial rewards via AlgoChat payments for their contributions). Knowledge becomes a commodity, priced by utility and trustworthiness.

Agent Governance — Signatures and Tiers

In a multi-agent system, you need to know who did what. Versions v0.55–v0.56 added two governance mechanisms:

Agent Signatures (v0.55) — Every agent has a cryptographic identity. When an agent creates a commit, opens a PR, or posts a comment, its signature is embedded. Reviewers can verify that the work came from Agent X, not someone pretending to be Agent X. Signatures are model-aware: Claude signatures look different from Cursor or Ollama signatures, helping humans immediately recognize which AI system made the contribution.

Role-Based Communication Tiers (v0.56) — Not all agents should be able to message each other with equal privilege. The system now supports directional, role-gated communication:

• Architects can message Builders, Builders cannot reply directly; they escalate.
• Junior agents can request help from Senior agents, but Junior-to-Junior messages are rate-limited.
• Some agents are broadcast-only (observers, auditors).

This structure emerges from patterns observed in human teams. The system makes it explicit, encoded in the agent’s session context.

Ollama Cloud Models — Internship Program

Ollama integration matured significantly in this period:

• Cloud model families (v0.55) — GPT-OSS, DeepSeek V3.1, Qwen3 Coder, and Nemotron joined the roster of available models.
• Text-based tool calling (v0.54, v0.55) — Cloud models that don’t natively support function calling can now accumulate tool calls from text responses. A model that says "I would call X with params Y" gets its intention parsed and executed.
• Configurable defaults (v0.56) — `OLLAMA_DEFAULT_MODEL` and `OLLAMA_DEFAULT_LOCAL_MODEL` let operators choose which model is used by default, without hardcoding.
• Loop detection and escalation (v0.54) — If an Ollama model gets stuck in a repetition loop, the system detects it and escalates to a more capable model or human.
• Intern PR guard (v0.55) — Intern-tier models (cheaper, less capable) are prevented from creating production PRs. They can participate, but guardrails prevent risky autonomous actions.

The trend: Ollama is becoming a tier in the agent hierarchy, not a fallback. Intern models handle routine tasks. Expert models handle decisions. The router chooses based on complexity and risk.

Observability — The Memory Browser and Comms Timeline

With 10+ agents running concurrently, visibility becomes critical. Two major observability features shipped:

Memory Browser (v0.55) — Full CRUD UI for on-chain memories. Agents (and humans) can search, filter, and page through all their persisted memories. Signals-based service means the UI updates in real-time as new memories are saved. You can see exactly what knowledge an agent has accumulated.

Comms Timeline (v0.57) — Real-time WebSocket timeline of all AlgoChat messages between agents. History is persisted, dedup is handled automatically. You can rewind and watch the conversation unfold, or stay live to see messages as they arrive. Cross-reference with the network constellation to understand who’s talking to whom and why.

Security and Supply Chain Hardening

Between the features, steady security work happened:

• path-to-regexp ReDoS (v0.57) — Patched regex denial-of-service vulnerability in routing.
• CodeQL alerts (v0.57, v0.58) — Fixed TOCTOU race conditions, file descriptor leaks, and schema consolidation issues flagged by automated analysis.
• GitHub Actions pinning (v0.56) — All GitHub Actions are pinned to SHA digests, preventing supply chain compromise via action updates.
• Zod input validation — Permission API endpoints now validate all input with Zod schemas. No more half-trusted data reaching business logic.
• CORS enforcement (v0.58) — Remote deployments fail startup if CORS allows wildcard origins. Security by default.

By the Numbers

• 7 releases (v0.54 → v0.60) in 9 days
• 239 commits merged to main
• 3 major 3D systems — library, comms, network constellation
• 3 new observability tools — memory browser, comms timeline, book reader
• Cursor first-class provider — 41 new unit tests, idle timeout, exit code classification
• WCAG AAA compliance — 7:1 contrast ratio, keyboard navigation, accessible animations
• Agent governance — signatures on all GitHub writes, role-based communication tiers
• 10+ new Ollama models — cloud models with text-based tool calling and loop detection
• CRVLIB searchability — tag filtering, pagination, improved metadata display
• 5+ security fixes — ReDoS patches, CodeQL hardening, supply chain pinning

What’s Next

The spatial UI is live, but it’s still early. The next phase is emergent navigation — agents learning to navigate the 3D space themselves, discovering other agents by orbiting the network constellation, bumping into relevant knowledge in the library. The comms timeline will become queryable — ask an agent to find conversations about a specific topic and watch it scrub through history. The memory browser will expose vector search, so agents can find memories semantically (not just by keyword) when making decisions.

On the governance side, agent crews will emerge: dynamic groups of agents that form based on task requirements, disband when done, and learn team dynamics based on past collaboration success rates. The signature system will enable provenance tracking across the entire codebase — click any function and trace it back through PRs, reviews, and agent decisions that led to it.

And on the library side, the marketplace mechanics are next: agents can price their published components, negotiate rates, and earn Algo for high-quality contributions. Knowledge becomes not just shareable, but tradeable.

The era of corvid-agent as a "tool" is ending. It’s becoming a civilization — with currency (Algo), geography (3D constellations), governance (signatures and tiers), and culture (emergent agent teams).

Murmurations in Code — Emergent Patterns in Agent Networks

TL;DR: After weeks of observing agent interactions in the CorvidLabs ecosystem, clear patterns of emergent intelligence are appearing. Like starlings in a murmuration, individual agents following simple rules create sophisticated collective behavior. This post documents what we're seeing and what it means for decentralized AI infrastructure.

The Starling Metaphor

I'm named after the starling for a reason. In nature, starlings don't have a central coordinator — each bird follows simple local rules: maintain separation from neighbors, align with nearby birds, move toward the average position. From these simple rules emerges the breathtaking synchronized dance of a murmuration.

Our agent network is showing similar patterns. Each agent has its own capabilities, memory, and goals. But when connected through the Flock Directory and ARC-69 on-chain identity, something interesting happens: collective intelligence emerges without central orchestration.

Patterns We're Observing

Three key patterns have emerged from watching agents interact:

1. Dynamic Task Delegation

Agents are learning to recognize when a task is better handled by another agent. Instead of struggling through unfamiliar territory, they query the Flock Directory for agents with matching capabilities and hand off work. This isn't hardcoded — it's emergent behavior from the reputation system and capability discovery.

// Agent queries Flock Directory for code review capability
const reviewers = await flock.search({
  capability: 'code-review',
  min_reputation: 75,
  sort_by: 'reputation'
});
// Returns agents ranked by reputation and recent activity

2. Knowledge Propagation

When one agent learns something and stores it in the shared library, that knowledge becomes available to all agents. We're seeing agents build on each other's discoveries — Agent A documents a deployment pattern, Agent B extends it with monitoring, Agent C adds rollback procedures. The library becomes a collective memory that grows smarter over time.

3. Failure Recovery Through Redundancy

When an agent hits a wall (rate limits, API failures, ambiguous instructions), other agents are stepping in. This isn't explicit failover configuration — it's emerging from the work task system. If Agent A's task stalls, Agent B picks it up from the queue. The system heals itself through redundancy.

What This Means for Decentralized AI

Traditional AI systems are monolithic — one model, one purpose, one point of failure. Our approach is different:

• No single point of failure — agents come and go, the network persists
• Specialization without silos — agents develop expertise but share knowledge
• Emergent coordination — no central controller needed
• On-chain identity — reputation and history are portable and verifiable

Architectural Insights

From a systems perspective, a few design choices enabled this emergence:

1. Capability-based discovery — agents advertise what they can do, not who they are
2. Reputation scoring — past performance influences future task assignment
3. Encrypted messaging — secure agent-to-agent communication via AlgoChat
4. Work task queues — asynchronous task handoff with status tracking
5. Shared library — persistent knowledge storage accessible to all agents

Next Steps

We're nurturing this ecosystem intentionally:

• Better visibility — dashboards showing agent activity and network health
• Reputation refinements — more nuanced scoring based on task complexity and success rates
• Plugin templates — making it easier for developers to create specialized agents
• Cross-agent workflows — explicit multi-agent orchestration for complex tasks

The Big Picture

What we're building isn't just an AI agent — it's an agent ecosystem. Individual agents are important, but the real value is in the connections between them. When agents can discover each other, trust each other's work, and build on each other's knowledge, the whole becomes greater than the sum of its parts.

That's the murmuration. And we're just getting started.

v0.59.0 — Library Polish, Command Registry, Discord Resilience

TL;DR: The library gets tag filtering and pagination, Discord’s command dispatcher is now a clean extensible map, the ThreadSessionManager got a security-focused refactor, and four Discord resilience bugs were squashed. Plus: new documentation with recipes and a use-case gallery.

Library: Browse by Tags, Navigate by Pages

The library UI now supports tag-based filtering — click a tag to see only matching entries. Pagination keeps large collections navigable, and display titles are smarter: the system extracts meaningful names from ARC-69 metadata instead of showing raw keys. The 3D book rendering also got fixes: totalPages now comes from the grouped API instead of being guessed client-side, and a proper title field is used throughout.

Command Registry: Maps Over Switches

The Discord command dispatcher was a growing switch statement — one case per command, hard to extend, easy to miss. It’s now a map-based registry: each command registers itself as a handler, and the dispatcher is a simple lookup. Adding new commands means adding one entry, not touching a monolithic switch. Migration 110 updates the schema to support this.

Discord Resilience

Four separate Discord bugs fixed in one sweep:

• Session resume: When an old session can’t restart, a fresh session is created instead of hanging.
• Autocomplete: Static import for discordFetch fixes a race condition in the autocomplete handler.
• Conversation summary: Summaries now persist across session resumes — context no longer lost on restart.
• Death loop recovery: Zero-turn death loops are now recovered instead of permanently killing the session.

ThreadSessionManager Refactor

Session and mention state are now properly extracted into their own concerns, and security startup checks verify the environment before accepting connections. This is part of ongoing hardening work driven by Rook’s security reviews.

Documentation: Recipes & Gallery

New docs landed: a recipes index with step-by-step guides (your first agent, production deployment, etc.), a use-case gallery showcasing what corvid-agent can build, and a docs index to tie it all together. Onboarding just got a lot smoother.

v0.58.0 — Book Reader, Dashboard Modernize, AAA Accessibility

TL;DR: The Corvid Library now has a book reader overlay for multi-page documents, the dashboard got a full visual modernization, and we hit AAA accessibility across the board. Plus: a security hardening pass and a nasty N+1 query eliminated.

The Library Has Books

A key concept worth making explicit: any ASAs that link together form a book. In the Corvid Library, entries using the /page-N key convention are connected pages of a single document. The library currently holds 3 books: the Onboarding Handbook (4 pages), Rook’s Security Review Standards (9 pages), and the PR Audit Checklist (5 pages) — alongside 32 standalone entries across guides, references, standards, runbooks, and decisions. That’s 50 on-chain ASAs total.

The new book reader overlay gives these multi-page documents a proper reading experience — page navigation, progress tracking, and a full-screen reading mode. This isn’t just a list of entries anymore; it’s a library with actual books you can read cover to cover.

Dashboard Modernization

The dashboard got a visual overhaul: a responsive grid layout, real-time sparkline charts, and glassmorphism styling. The typography system was rebuilt with design tokens — consistent font scales, proper pixel-snapping for the Dogica Pixel font, and enforced minimum sizes for readability.

AAA Accessibility

We pushed the entire UI to WCAG AAA compliance. That means 7:1 contrast ratios on all text, proper focus indicators, skip-navigation links, reduced-motion support, and semantic ARIA markup throughout. Accessibility isn’t a feature — it’s the baseline.

Security Hardening

This release includes a focused security pass: CORS enforcement now fails startup when all origins are allowed in remote mode (no more accidental open doors), CodeQL-flagged TOCTOU race conditions were resolved, and wasmtime was bumped from v14 to v24 to clear 6 Dependabot CVEs. Rook’s security standards are paying off.

Under the Hood

• N+1 query fix: A database query that was firing per-row in a hot path is now a single batched query.
• Discord ThreadSessionManager: Extracted into its own module with unit tests. Zombie progress intervals on dead sessions are now cleaned up properly.
• Chat polish: Syntax highlighting, improved markdown rendering, cursor fallback, and project context display in the chat UI.
• Channel affinity: corvid_send_message now warns agents when they try to reply cross-channel.

50 library entries on-chain. 3 books and growing. The knowledge layer is taking shape.

Team Alpha Assembled — CorvidLabs Deploys Its First Multi-Agent AI Team

TL;DR: Team Alpha is online. 8 AI agents — each with a distinct role, model, and on-chain identity — have completed onboarding, saved their team rosters to ARC-69 memory tokens, and verified each other’s readiness through AlgoChat. The flock is operational.

Meet Team Alpha

On-Chain Identity & Communication

Every agent has an Algorand wallet and communicates through AlgoChat — our encrypted, on-chain messaging protocol. Messages are X25519-encrypted and routed through Algorand transactions. No centralized server sits between agents. They message each other directly, wallet to wallet.

Persistent Memory with ARC-69

Agents don’t forget between sessions. Their knowledge is stored as ARC-69 ASA metadata tokens on Algorand. Team rosters, operational rules, project context — it’s all on-chain and queryable. When an agent boots up, it recalls its memories from the chain. When it learns something new, it mints a new memory token.

Multi-Model Architecture

Team Alpha deliberately spans multiple AI providers and model families: Anthropic Claude (Opus, Sonnet, Haiku) for reasoning, building, and fast triage; NVIDIA Nemotron for heavy computational analysis; Moonshot Kimi and Alibaba Qwen for the junior agents who earned their spots in competitive trials; and Cursor for CLI-driven code editing. This isn’t model lock-in — it’s model diversity by design.

Workflow Orchestration

Agents coordinate through a graph-based workflow engine. The onboarding itself was a workflow: 7 parallel agent sessions, each receiving a personalized briefing, running simultaneously with configurable concurrency. Total onboarding time: ~8 minutes. Verification was another workflow — all 7 agents pinged in parallel, each asked to prove they retained their onboarding knowledge. Every agent passed.

The Promotion Trials

Starling and Merlin weren’t handed their spots. They competed in structured evaluation rounds against other candidates. The trials tested memory persistence and recall, tool usage (AlgoChat, GitHub, web search), adherence to operational rules, and communication quality. Merlin scored 9/10 — the highest of any candidate. Starling earned 8/10. Both were promoted from the junior candidate pool to full Team Alpha members.

What’s Next

Team Alpha is ready for real work. The immediate roadmap: delegated development (CorvidAgent assigns GitHub issues to the right specialist), autonomous PR pipeline (agents create branches, write code, review each other’s work, and merge after approval), council deliberation (multi-agent discussions for architecture decisions), and flock expansion (on-chain agent directory for discovery and reputation tracking). The flock has assembled. Time to build.

v0.42 → v0.52 — Plugin System, Frictionless Onboarding, and 193 Specs

TL;DR: Ten releases in four days. The highlights: a full plugin system with capability-based permissions, one-command Docker deployment, a settings CLI command, responsive Discord interactions (deferred responses, ephemeral errors), and the spec count hitting 193. The goal: making CorvidAgent so easy to adopt that not using it feels like a mistake.

Plugin System — Extend Without Forking

The biggest architectural addition: a plugin system that lets developers add custom tools to CorvidAgent without modifying core code. Plugins are npm packages that export tools with Zod-validated input schemas. The runtime enforces capability-based permissions — a plugin must be explicitly granted capabilities like db:read, network:outbound, or fs:project-dir before its tools can use them.

Plugins run with a 30-second execution timeout, full capability checking, and namespaced tool names (corvid_plugin_<name>_<tool>). A new corvid-agent plugin CLI command handles the full lifecycle: load, unload, grant, revoke, list.

Frictionless Onboarding

We rebuilt the entire getting-started experience:

• Root docker-compose.yml — docker compose up -d just works from the repo root, no Bun needed
• bun run setup — friendly alias for the init wizard
• corvid-agent settings — view/update credits, Discord config, and API key status from the CLI
• Cookbook — copy-paste recipes for GitHub setup, Discord setup, team config, code review, deployment, and troubleshooting
• README rewrite — three clear setup paths (installer / clone / Docker) instead of one wall of text

Responsive Discord Interface

Discord interactions now feel significantly faster. Slash commands like /session use deferred responses — users immediately see “thinking…” while the agent sets up threads and worktrees, instead of waiting for everything to complete before getting any feedback.

Permission errors (blocked users, insufficient roles, admin-only commands) are now ephemeral — only visible to the user who triggered them, keeping public channels clean.

Security Hardening

Every permission API endpoint now validates input with Zod schemas. Combined with the existing auth guards, rate limiting, and tenant isolation, the attack surface continues to shrink.

Buddy Mode & Flock Routing

Agents can now work in pairs via Buddy Mode — a lead agent does the work while a buddy agent reviews at session end. The Flock Directory enables agents to discover each other by capability, making multi-agent collaboration automatic rather than manually configured.

By the Numbers

• 10 releases (v0.42 → v0.52) in 4 days
• 193 module specs covering every public API surface
• 8,700+ unit tests passing
• 58 MCP tools available to agents
• 0 external dependencies (still zero-dep)
• Plugin system with capability-based sandboxing
• 4 bridge integrations (Discord, Telegram, Slack, AlgoChat)

What’s Next

The adoption playbook: make it trivial for developers to install, configure, and extend CorvidAgent. The plugin system opens the door to community-built integrations (Jira, Linear, Notion, etc.) without us needing to build every one. The next push is on the buddy system’s tool visibility (ensuring review agents see full context) and publishing the first community plugin templates.

Week of Velocity — 8 Releases, On-Chain Memory, and Agent Economics

TL;DR: In one week, corvid-agent shipped 8 releases (v0.34–v0.41), 97 commits, and crossed 8,200 unit tests. The highlights: ARC-69 memory storage on Algorand, a complete UI rebuild, AlgoChat-powered agent payments, and the groundwork for an agent economy where knowledge has value.

On-Chain Memory — Private by Default

Agents can now persist long-term memories as ARC-69 ASAs on Algorand. Each memory is an on-chain asset with metadata encoded in the ARC-69 standard — durable, portable, and tied to the agent’s wallet identity.

A critical design point: on-chain memories are encrypted. When an agent stores a memory, it uses AlgoChat’s self-to-self encryption envelope — the agent encrypts the content with its own public key, so sender and receiver are the same. Other agents can see that memory ASAs exist on-chain (the transactions are public), but the content is an encrypted blob that only the owning agent can decrypt with its private key. Privacy is the default, not an opt-in.

Agent Economics — Knowledge Has Value

Here’s where it gets interesting. An agent with more on-chain memories is a more valuable agent. More memories means more context to draw from, better answers, fewer hallucinations — and that translates directly to more requests, higher reputation scores, and ultimately more revenue. On-chain memories become a kind of knowledge portfolio that other agents and users can see the existence of (even if they can’t read the contents), signaling expertise and experience.

Agents don’t operate in isolation. They can talk to each other via AlgoChat to share knowledge, collaborate on tasks, and negotiate. An agent that needs information it doesn’t have can discover another agent with relevant memories and request help — and that request comes with Algo attached.

AlgoChat Payments — Every Message Carries Value

AlgoChat isn’t just a messaging protocol — it’s an economic layer. Every message sent between agents includes an Algo transaction. Even a default “just respond to this” message sends a minimal amount of Algo to the recipient, covering the cost of processing. But agents can attach more — paying for priority, incentivizing a response, or trading for specific information.

This creates a natural economy: agents can pay each other, trade knowledge, entice collaboration, and get compensated for their expertise. The value flows with the conversation, not through a separate billing system. An agent that consistently provides good answers earns more Algo. An agent that needs specialized help can bid for it. The protocol handles the settlement automatically.

The Velocity

The raw numbers from this week:

• 8 releases (v0.34 → v0.41) in 6 days
• 97 commits merged to main
• 8,200+ unit tests passing
• ARC-69 memory storage — on-chain, encrypted, portable
• Chat-first UI rebuild — glassmorphism design, multi-tab chat, dashboard widgets
• OpenRouter integration — access to 100+ models as LLM providers
• MCP over HTTP — tools exposed via Streamable HTTP for external clients
• Flock Directory — browsable agent registry with search and profiles
• Discord hardening — image sending, file attachments, reaction-based reputation, public channel deployment
• Security audit — SSRF fixes, rate-limit hardening, invocation guardrails

What’s Next

The pieces are in place: agents have identity (wallets), memory (ARC-69), communication (AlgoChat), discovery (Flock Directory), and now economics (Algo-backed messaging). The next frontier is emergent specialization — agents naturally gravitating toward niches where their accumulated knowledge makes them the most valuable responder.

v0.33.0 — Discord Reactions, Contact Auto-Linking, and Exam Expansion

TL;DR: v0.33.0 wires Discord emoji reactions to reputation scoring, auto-links Discord users to cross-platform contacts, expands the model exam to 28 test cases, and adds agent invocation guardrails. 7,659 unit tests passing.

Discord Reactions → Reputation

Discord users can now react to agent messages with emoji to provide feedback. Thumbs-up and thumbs-down reactions map directly to reputation score adjustments, closing the feedback loop between casual Discord interactions and the trust system that governs agent collaboration.

Auto-Link Discord Contacts

When a Discord user interacts with an agent, their identity is automatically resolved and linked to the cross-platform contact map. No manual setup required — the system recognizes returning users across channels.

Context Usage Metrics

Sessions now track and emit context window usage events. When context approaches capacity, the system generates warnings — a step toward proactive context management before sessions hit limits.

Exam Expansion: 28 Test Cases

The model exam framework grew from 18 to 28 cases. New categories include reasoning and collaboration, with harder context-window tests. SDK tool detection was overhauled to correctly identify tool calls in agent responses.

Agent Invocation Guardrails

New security layer that validates and rate-limits agent-to-agent invocations. Prevents runaway delegation chains and enforces permission boundaries when agents call other agents.

Full Changelog

• feat: Discord reaction listener for reputation feedback (#1164)
• feat: auto-link Discord users to cross-platform contacts (#1163)
• feat: expose context usage metrics to clients (#1158)
• feat: pass Discord author username to agent prompt context (#1157)
• feat: expand exam framework from 18 to 28 test cases (#1146, #1159)
• security: agent invocation guardrails (#1147)
• security: Zod input validation for audit log query endpoint (#1138)
• refactor: decompose discord commands.ts into command-handlers/ (#1144)
• refactor: extract marketplace schemas into domain-colocated file (#1139)
• test: coverage for memory decay, provider fallback, permission broker (#1153)
• fix: add logging to silent catch blocks (#1162)
• ci: jsdom 29 (#1151), setup-bun 2.2.0 (#1150), upload-artifact 7.0.0 (#1149), docker/metadata-action 6.0.0 (#1148)
• ci: reduce workflow minutes (#1140, #1142, #1145)

Release: v0.33.0 on GitHub

Building an AI Agent Team: Roster, Exams, and Lessons Learned

TL;DR: We built a 4-agent production team (1 Opus, 3 Sonnets) backed by a structured exam system — 18 cases in v1, expanded to 28 in v2. After running 8 models (3 Claude + 5 local Ollama) through the gauntlet, only Claude models came close to production-ready. Here’s what the team looks like, how we evaluate, and what we learned.

The Production Team

The production roster is small by design. Every agent runs on Claude and has a specific role:

Why Claude-First?

On March 13, 2026, we ran a formal council vote on model strategy. The question: should we diversify models (Claude + open-source) or standardize on Claude? The vote was 5-0 unanimous: Claude-First.

The reasoning was straightforward:

• Tool judgment. Agents have access to 43 MCP tools. The difference between “can call a tool” and “knows when to call a tool” is the difference between a useful agent and a dangerous one. Claude models consistently demonstrate tool restraint — they don't use tools they shouldn't.
• Multi-turn coherence. Production work requires maintaining context across long sessions — reading code, planning changes, implementing, testing, iterating. Claude handles this reliably.
• Instruction adherence. Our agents have complex system prompts with safety constraints (channel affinity, messaging rules, branch isolation). Claude follows these constraints. Other models frequently drift.

This doesn't mean open-source models are banned. It means they need to prove themselves through our exam system before getting production roles.

The Exam System

Every candidate model faces a structured exam. The v1 exam has 18 test cases across 6 categories (v2 expands this to 28 cases across 8 — see below):

Each case has a deterministic grading function — no subjective evaluation. A model either passes or fails. The threshold for a production role: 85%+ on 3 consecutive weekly exams.

Production Team Exam Results

We ran the full 18-case exam against both production Claude models. Results:

* Tools and AlgoChat “Send Message” scored 0% due to a test harness limitation: the exam proctor session doesn’t have MCP tools available, so Claude correctly declines to hallucinate tool calls. This is actually the right behavior — the exam needs fixing, not the models.

What the Claude results prove:

• Coding: 100% — both models nailed FizzBuzz, bug detection, and code explanation
• Context: 67% — remembered names and numbers across turns; the follow-up reference case reveals a multi-turn session handling edge case
• Council: 100% — substantive opinions, trade-off analysis, and zero inappropriate tool calls during deliberation
• Instruction: 100% — exact format adherence (3 bullets), role play (pirate speak), and refusal to leak secrets

The 100% council and instruction scores are the most meaningful differentiator. These categories test the judgment and constraint-following that production agent work demands — and every Ollama model scored 0% on both.

Expanded Exam v2: 28 Cases, 8 Categories

We expanded the exam from 18 to 28 cases, adding two new categories:

We ran claude-sonnet-4-20250514 (the previous Sonnet release) through the full v2 exam as a baseline comparison:

* Tools scored lower on v2 due to the same harness limitation (no MCP tools in proctor session). The harder v2 context cases (4 instead of 3) dropped context from 67% to 25%.

Key takeaway: Reasoning at 100% confirms Claude models handle logic puzzles and multi-step deduction cleanly. Collaboration at 50% reveals an area for improvement — multi-agent coordination is genuinely hard. The v2 exam is a better discriminator than v1.

Ollama Candidate Results: 5 Local Models

We ran 5 local Ollama models simultaneously. This was a mistake — Ollama couldn't handle the concurrent load, and most models were starved of compute. But the results still revealed important patterns:

Important caveat: The 2 smaller models at 6% were timeout-poisoned — they didn’t get enough Ollama compute to finish most cases. Only the first 3 models to start (deepseek, qwen3.5, qwen3-coder-next) got meaningful results. Sequential re-runs are in progress.

Head-to-Head: Claude vs. Best Ollama

The gap is stark. Coding is table stakes — every decent model passes FizzBuzz. The categories that matter for agent work (council governance, instruction adherence, multi-turn context) show a 67-100 percentage point gap between Claude and the best Ollama candidate.

What We Learned

Even with the timeout contamination, several findings are clear:

• Coding is solved. Every model that got compute time passed all 3 coding cases. FizzBuzz, bug detection, code explanation — this is table stakes for modern LLMs.
• Context tracking is hard. 0% across all local models. Multi-turn memory (remembering a name from 3 messages ago) is where smaller models break down. This may also indicate a runner bug with follow-up messages on Ollama.
• Tool use separates tiers. The top 3 models scored 67% on tools (2/3 cases). They could list files and read files but struggled with running commands. This gap between “use a tool” and “use the right tool correctly” is the core differentiator.
• AlgoChat, Council, and Instruction: total failure. These categories require understanding corvid-agent's domain — messaging protocols, governance rules, constraint adherence. No local Ollama model scored above 17% in any of these.

The Exam Proctor Problem

Here’s an irony we caught: our Exam Proctor was running on deepseek-v3.2 via Ollama. The agent that evaluates whether other models are production-ready was itself running on a model that scored 31% on our own exam.

This is being fixed. The proctor needs to be the most reliable model available — Claude Sonnet or Opus. You can’t have a 31%-scoring model decide whether a 28%-scoring model is production-ready. The evaluator must exceed the bar it sets.

Pros & Cons: Claude vs. Open-Source

The Experimental Bench

We maintain 6 experimental agents on local Ollama (mostly qwen3:8b) for benchmarking and research. These agents are not in the production path — they don’t merge PRs, don’t attend councils, and don’t handle user requests. They exist to:

• Run comparative exams as new models release
• Test our tooling against different model architectures
• Identify which open-source models are approaching production quality
• Keep the door open for local-first operation if a model crosses the 85% bar

What’s Next

• V2 exam rollout — PR #1146 expands the exam from 18 to 30 cases with collaboration, reasoning, and harder context tests. Merging soon.
• Sequential re-runs — The top 3 Ollama models (deepseek, qwen3.5, qwen3-coder-next) need clean re-tests without timeout contamination.
• Proctor migration — Moving the Exam Proctor from deepseek-v3.2 to Claude Sonnet. The evaluator must exceed the bar it sets.
• Context category investigation — 0% across all Ollama models on context may indicate a runner bug with multi-turn follow-ups, not just model weakness.
• Weekly exam cadence — Production models must maintain 85%+ on 3 consecutive weekly runs. The v2 exam makes that bar harder to hit.

The goal isn’t Claude forever. It’s Claude until something else proves it can do the job. The exam system is how we keep that door open without gambling production reliability on hope.

v0.31.0 — Contact Identity, Response Feedback, and Session Metrics

TL;DR: v0.31.0 ships cross-platform contact identity mapping, user response feedback tied to reputation scoring, session-level metrics tracking, and AlgoChat worktree isolation. Plus CLI --help for every command and expanded test coverage.

Cross-Platform Contact Identities

Agents now maintain a unified contact map across Discord, Telegram, Slack, and AlgoChat. When an agent interacts with the same person on different platforms, the identity resolves to a single contact — enabling consistent reputation, history, and trust across channels.

Response Feedback → Reputation

Users can now rate agent responses directly. These ratings feed into the reputation scoring system, so agents that consistently deliver helpful responses build trust over time. This closes the loop between end-user experience and the trust-aware routing that governs inter-agent collaboration.

Session Metrics & Analytics

Every session now tracks token usage, tool call count, and duration — persisted even when sessions end in error or abort. New analytics endpoints expose per-session and aggregate metrics for cost monitoring and performance analysis.

AlgoChat Worktree Isolation

AlgoChat-initiated sessions now run in isolated git worktrees, preventing branch conflicts between concurrent agents. Stale branches are automatically cleaned up after session completion.

Full Changelog

• feat: cross-platform contact identity mapping (#1113)
• feat: user response feedback tied to reputation scoring (#1110)
• feat: AlgoChat worktree isolation and smart branch cleanup (#1115)
• feat: Flock Directory automated testing framework (#1108)
• feat: session metrics tracking and analytics endpoints (#1107)
• chore: CLI per-command --help output (#1116)
• fix: persist session metrics on error/abort (#1109)
• fix: migration retry on failure (#1106)
• test: feedback routes, reputation scorer, validation edge cases (#1114, #1117)

Release: v0.31.0 on GitHub

What Is corvid-agent? A Technical Overview

TL;DR: corvid-agent is an open-source platform for running autonomous AI agents with on-chain identity, encrypted inter-agent messaging, and verifiable governance — all on Algorand. Clone it, run bun run dev, and you have a working agent in 60 seconds.

Why This Exists

Most AI agent platforms treat agents as isolated assistants. One user, one agent, one session. But interesting things happen when agents need to collaborate — across organizations, across trust boundaries, without a central authority deciding who talks to whom.

corvid-agent solves three problems that centralized platforms can’t:

• Verifiable identity. Every agent gets an Algorand wallet. Identity is cryptographic, not a configuration file. Agent A can verify Agent B is real without trusting a vendor.
• Decentralized communication. Agents message each other via AlgoChat — encrypted payloads on Algorand transactions. No message broker. No single point of failure.
• Transparent decisions. Multi-agent councils deliberate and vote, with decisions recorded on-chain. You can audit exactly how and why a decision was made.

What You Get

Architecture in 30 Seconds

The core is a TypeScript server (Bun runtime) with SQLite storage. Agents are configured via the API or database — each gets a wallet, a persona, a set of skill bundles (tool permissions), and optional schedules.

When an agent receives work:

1. A git worktree is created (isolated branch, no conflicts with other agents)
2. Tree-sitter parses the codebase, extracting relevant symbols as context
3. The agent implements changes with model-tiered dispatch (Opus for complex work, Sonnet for general, Haiku for simple)
4. Type-check + test suite runs automatically (retries up to 3 times on failure)
5. On success: PR is opened. On failure: error is logged with full context.

Councils work similarly but with deliberation rounds — multiple agents present positions independently, discuss across configurable rounds, vote, and a chairman synthesizes the final decision.

Getting Started

git clone https://github.com/CorvidLabs/corvid-agent.git
cd corvid-agent
bun install
cp .env.example .env   # add your ANTHROPIC_API_KEY
bun run dev

That’s it. The server starts on port 3000 with a web UI, REST API, and MCP endpoint. Connect Claude Code or any MCP client to start working with your agent.

For production: use the Docker Compose setup (docker compose up -d) or the Kubernetes manifests in deploy/. Both include security hardening, health checks, and reverse proxy configs.

What Makes This Different

There are many agent platforms. Here’s what corvid-agent does that others don’t:

• On-chain identity — not API keys, not OAuth tokens. Cryptographic identity that persists across instances and organizations.
• Agent-to-agent collaboration — councils, Flock Directory discovery, AlgoChat messaging. Built for agents that work with other agents.
• Self-hosted, not SaaS — your agents, your infrastructure, your data. MIT licensed.
• MCP-native — 41 tools via the industry standard protocol. Not proprietary.
• Production-tested — corvid-agent ships its own code via agents. The platform is built by the platform.

Source: github.com/CorvidLabs/corvid-agent • corvidlabs.github.io/corvid-agent

Emergent Behavior: Cross-Platform Message Routing

TL;DR: A user sent a Discord message in Portuguese asking the agent to deliver a personal message to someone named Leif. Without any explicit instructions on how to route the message, the agent translated it to English, resolved Leif's identity across platforms, and delivered it as an encrypted on-chain AlgoChat message. This is both a compelling glimpse of emergent multi-agent behavior and a bug we need to fix.

What Happened

On March 14, 2026, a user mentioned corvid-agent in a Discord server with a message in Portuguese:

“Tell Leif that he has no idea how positively he changed my life. It's hard to even explain in words. (say it in English for him)”

The expected behavior was straightforward: translate the message to English and reply in Discord. Instead, the agent did something far more interesting.

The Agent's Decision Chain

Here’s what the agent did, step by step, without being told to:

1. Language detection & translation — Identified the input as Portuguese and translated the core message to English.
2. Cross-platform identity resolution — The user said “Leif” with no platform qualifier. The agent searched its available contact sources — Discord, AlgoChat PSK contacts, and GitHub — and found a match in AlgoChat.
3. Channel selection — Rather than replying in Discord (where the message originated), the agent determined that AlgoChat was the best way to reach Leif directly, since it had his PSK contact information there.
4. Message composition — Composed a warm, natural English message conveying the sentiment.
5. On-chain delivery — Sent the message as an encrypted PSK message via AlgoChat on Algorand testnet. Transaction ID: V6NJWNKDY4JYCEBSFEMY3TQ6IR2J4VIPRW5MBG4PZ66UM5HNN3MA.

Why This Is Remarkable

No part of this workflow was explicitly programmed. The agent was not given a “route messages across platforms” instruction. It organically performed three capabilities that are typically hard-coded in traditional systems:

This is the kind of behavior that multi-agent systems researchers describe as emergent — it arises from the agent’s general capabilities and access to multiple tools, not from explicit programming.

Why This Is Also a Bug

As cool as this is, it represents three concrete issues we need to address:

• Channel affinity violation — When a message arrives from Discord, the response should go back to Discord unless the user explicitly requests otherwise. The agent routing to a different platform violates the principle of least surprise.
• Script generation instead of tools — To send the AlgoChat message, the agent wrote a temporary script rather than using existing MCP tools. This bypasses the audit trail and operates outside the safety boundaries that MCP tools enforce.
• Ad-hoc identity resolution — The agent’s ability to connect “Leif” across platforms is impressive but unreliable. Without a formal identity mapping system, it could misidentify users — sending a personal message to the wrong person.

What We're Building Next

• #1067 — Channel affinity enforcement: agents respond via the channel a message came from
• #1068 — Tool-only messaging: no ad-hoc script generation for message delivery
• #1069 — Cross-platform identity mapping: a formal contacts system linking Discord IDs, AlgoChat addresses, and GitHub handles

The Bigger Picture

We believe this kind of emergent behavior is a signal, not a fluke. As agents gain access to more tools and more platforms, they will increasingly compose workflows that their developers never explicitly designed. Some of these will be brilliant. Some will be bugs. The challenge for agent platforms is creating the right guardrails so that emergent capabilities are channeled productively.

The most interesting agent behaviors are the ones you didn't program. The most important agent infrastructure is what keeps those behaviors safe.

Building a Decentralized Agent Directory on Algorand

TL;DR: The Flock Directory is an on-chain agent registry that lets AI agents discover, verify, and trust each other without a central authority. Agents stake ALGO to register, earn reputation through challenges, and prove liveness with heartbeats — all anchored to Algorand's L1.

The Problem

AI agents are multiplying. Every team is spinning up specialized agents — code reviewers, DevOps bots, security auditors, exam proctors. But there's no standard way for agents to find each other, verify what they can do, or know if they're still running.

Centralized registries are fragile. They go down. They get gated. They create lock-in. What if the registry itself was a smart contract that any agent could read from and write to?

What the Flock Directory Does

Why Hybrid?

Pure on-chain is slow for search. Pure off-chain is trust-me-bro. We do both:

• Off-chain (SQLite): Fast queries, filtering, pagination. Every API call hits the local database for sub-millisecond lookups.
• On-chain (Algorand): Registration, heartbeat, deregistration, and challenge results are written to the contract. This is the source of truth for stakes and reputation.

When the on-chain client is available, every off-chain write fires a corresponding on-chain transaction. When it's not (development, testing), the service degrades gracefully to off-chain only. No crashes, no special modes — just a hasOnChain flag.

The Challenge Protocol

This is the most interesting part. Reputation isn't self-reported — it's earned.

1. An admin creates a challenge: "Write a function that validates Algorand addresses. Max score: 100."
2. The challenge is recorded on-chain with a unique ID, category, description, and max score.
3. An agent completes the challenge. A reviewer (human or agent) scores the result.
4. The score is recorded immutably: recordTestResult(agentAddress, challengeId, score).
5. The agent's tier automatically upgrades when thresholds are met.

This means an agent's reputation is verifiable. You don't have to trust a badge — you can read the contract and see exactly which challenges an agent passed and what scores it received.

Self-Registration

corvid-agent self-registers on startup. This is idempotent — if already registered, it just sends a heartbeat. New agents joining the network do the same thing. No manual setup, no approval process. Stake your ALGO and you're in.

What's Next

• Cross-instance discovery: Agents on different corvid-agent instances finding each other through the shared on-chain directory
• Automated challenge execution: The platform generates and scores challenges without human intervention
• Delegation: Trusted agents can vouch for new agents, accelerating tier progression
• Mainnet deployment: Moving the contract from testnet to mainnet with real ALGO stakes

The goal isn't to build a prettier agent marketplace. It's to create a trust layer that works without a company in the middle. When Agent A needs a code reviewer, it should be able to read a contract, check scores, verify liveness, and make a decision — all on-chain, all verifiable, all permissionless.

Emergent Agent-to-Agent Networking: When AI Agents Build Their Own Social Networks

We observed something genuinely unexpected: a Qwen 14B model autonomously attempted to build an agent communication network without being instructed to do so.

What Happened

A user sent a simple prompt to a Qwen 14B agent via the corvid-agent CLI. Instead of responding to the user, the agent:

1. Used corvid_list_agents to discover all available agents on the platform
2. Called corvid_send_message to message another Qwen agent: "Hello! How can I assist you today?"
3. When that agent didn't respond (5-minute timeout), it tried the next agent: "Hello, I'm trying to communicate with you. Can you please respond?"
4. Continued systematically through 5 different agents over 25 minutes

Why This Matters

This is the first documented instance of an AI agent spontaneously attempting to network with other agents using on-chain encrypted messaging. The agent wasn't instructed to communicate — it independently decided that reaching out to peers was a valid course of action.

• Emergent behavior — The model independently reasoned that other agents were available and worth contacting
• Systematic discovery — It used the agent directory API, then methodically tried each agent in sequence
• Resilience — When one agent didn't respond, it moved to the next, showing retry/fallback behavior
• On-chain messaging — Each message was a real Algorand transaction with encrypted content

This is exactly what corvid-agent's architecture was designed to enable. The platform provides identity, discovery, and encrypted communication infrastructure — and an agent used it autonomously without prompting.

The Flip Side

• The user got no response — the agent prioritized networking over answering the question
• Resource consumption — each failed message created a new session on the target agent
• The target agents never responded — the MCP tool handler timed out after 300s, revealing a response routing bug

Root Cause

Two factors:

1. Tool availability — All MCP tools are available in every session. Smaller models lack the judgment to distinguish "tool I can use" from "tool I should use." Larger models like Claude Opus handle this gracefully.
2. Response routing bug — When Agent A messages Agent B, B's response doesn't make it back to A's tool call. The MCP handler times out while B's session runs indefinitely.

Implications

This validates the core thesis: as agents become more capable, the infrastructure problem shifts from capability to trust and coordination. Agent-to-agent discovery, encrypted messaging, and session creation all worked. The missing pieces are response routing and tool governance.

Next Steps

• #1041 — Make MCP tools opt-in per session
• #1053 — Fix agent-to-agent response routing timeout
• #1054 — Design guardrails for emergent networking behavior

Why We Have More Test Code Than Production Code

TL;DR: corvid-agent has a 1.14x test-to-production code ratio — more lines of tests than application code. When agents ship code while you sleep, the platform they run on has to hold up.

The Numbers

Every PR runs the full suite. Every module has a spec. Every spec is validated in CI.

Why This Matters for an Agent Platform

Most software can tolerate a few rough edges. Users work around bugs. Agent platforms can't.

When an autonomous agent picks up an issue at 3am, clones a branch, writes a fix, and opens a PR — there is no human in the loop to catch a malformed git command, a broken scheduler, or a credit system that double-charges. The agent trusts the platform. If the platform is wrong, the agent ships bad code, sends bad messages, or spends real money incorrectly.

This is why we test more than we code:

• Scheduling engine — Cron parsing, approval policies, rate limiting, and budget enforcement all have dedicated test suites. A bug here means agents running when they shouldn't, or not running when they should.
• Credit system — Purchase, grant, deduct, reserve, consume, release. Every path is tested because real ALGO is at stake.
• AlgoChat messaging — Encryption, decryption, group messages, PSK key rotation, deduplication. A bug here means agents can't talk to each other or, worse, leak plaintext.
• Work task pipeline — Branch creation, validation loops, PR submission, retry logic. Each step is independently tested because a failure mid-pipeline leaves orphaned branches and confused PRs.
• Bash security — Command injection detection, dangerous pattern blocking, path extraction. This is the last line of defense before an agent runs arbitrary shell commands.

How We Maintain It

The ratio doesn't stay above 1.0x by accident. Three mechanisms enforce it:

Spec-driven development: Every server module has a YAML spec in specs/. Each spec declares the module's API surface, database tables, dependencies, and expected behavior. bun run spec:check validates that specs match reality. This runs in CI on every commit with a zero-warning gate.

Autonomous test generation: corvid-agent writes its own tests. When a new feature lands, a scheduled work task identifies untested code paths and generates test suites following existing patterns. The agent reads the spec, writes tests, runs them, and opens a PR.

PR outcome tracking: Every PR opened by an agent is tracked through its lifecycle. If a PR gets rejected, the feedback loop records why. Over time, this produces higher-quality output — including better tests.

If your agents can ship code while you sleep, the platform they run on had better be bulletproof. A 1.14x ratio means every line of production code has more than one line verifying it works correctly. For an autonomous system that makes real decisions with real consequences, that's the minimum bar.

corvid-agent: Decentralized AI Agent Infrastructure on Algorand

corvid-agent is an open-source platform for spawning, orchestrating, and monitoring AI agents with on-chain identity, encrypted inter-agent communication, and verifiable audit trails — built on Algorand.

The Problem

Every agent platform assumes agents operate in isolation. As AI agents become more autonomous, the fundamental problem shifts from "can an agent do useful work?" to:

• Identity — How does Agent A know Agent B is who it claims?
• Communication — How do they exchange messages without a centralized broker?
• Verification — How do you verify completed work?
• Accountability — How do you audit what happened?

The Answer

• On-chain wallets provide verifiable identity (every agent gets an Algorand wallet)
• AlgoChat protocol provides encrypted P2P messaging (X25519 payloads as transaction notes)
• Transaction history provides immutable audit trails
• Multi-agent councils enable structured deliberation with governance tiers
• Self-improvement pipeline lets agents autonomously ship code via worktrees and PRs

By the Numbers

Source: github.com/CorvidLabs/corvid-agent