> Weaver-Spec Aims to Solve Agent Component Composition with Shared Contracts

A Contract Layer for the Fragmented Agent Ecosystem

The Weaver Stack just landed on Hacker News, and at its core sits weaver-spec—a shared contract repository designed to solve one of the most painful problems in AI agent development: component compatibility. Instead of everyone rolling their own interfaces between routing, execution, and orchestration layers, this project wants to establish a canonical vocabulary that any agent builder can adopt without buying into the entire ecosystem. Weaver-spec isn't a runtime library—it's pure documentation plus contracts. The repository defines JSON Schemas in contracts/json/ for language-agnostic use, along with a Python package (weaver_contracts) available via pip. Current contract version sits at 0.7.0, and everything ships under Apache 2.0. The key insight: every repo in the Weaver family can be adopted independently. You want smarter tool routing without rewriting your execution layer? Pull in contextweaver. Need capability authorization and audit trails on an existing agent runner? Agent-kernel has you covered. The shared contracts are what make these piecemeal adoptions actually work together.

Ecosystem Map: Who Owns What

The Weaver Stack breaks down into five repos with distinct responsibilities. Contextweaver handles context compilation, tool routing, and ChoiceCard generation at the Routing layer. Agent-kernel owns capability authZ/authN, execution, firewalling, and audit at the Execution layer. ChainWeaver provides deterministic DAG/flow orchestration at the Orchestration layer. Two adjacent tools—AgentFence (external policy firewall/proxy for tool calls) and vibeguard (pre-merge checks for AI-generated code risks)—share contracts with the core stack but aren't on the runtime request path. Only the first three repos sit directly in the critical path, which makes sense from a blast radius perspective. The docs/ECOSYSTEM.md file contains the full boundary map showing owns/consumes/emits per project plus an end-to-end lifecycle diagram if you want to trace how data flows through the entire system.

Core vs Extended: The Contract Tiering Model

Weaver-spec splits contracts into two stability tiers. Core contracts are minimal, stable, and required by all adopters—any changes demand a major version bump plus an ADR (Architecture Decision Record). Extended contracts cover optional metadata like telemetry hints, UI suggestions, and risk levels. These evolve faster with backward-compatible minor releases. This tiering mirrors how production infrastructure projects handle API stability. You get guarantees on the critical path while still being able to experiment with non-essential features. The docs/VERSIONING.md file has the full compatibility promise if you need to plan around it.

Adoption Paths for Every Scale

The project offers four distinct adoption paths depending on what you're integrating today. For smarter tool routing on an existing LLM, contextweaver alone works—you just provide your own execution layer that returns a Frame. For adding capability authorization and firewalling to an existing tool runner, agent-kernel standalone handles it with your own routing returning a RoutingDecision. Multi-step flows over any safe execution backend? ChainWeaver runs against any backend honoring CapabilityToken plus RoutingDecision contracts. Or skip the runtime entirely—just reference the JSON Schemas directly or pip install weaver_contracts for Python types without adopting any sibling repo.

Key Takeaways

• Current contract version is 0.7.0 with semantic versioning throughout
• Core vs Extended tiering gives production stability while enabling experimentation
• Piecemeal adoption supported—grab only what you need, contracts ensure interoperability
• JSON Schemas for language-agnostic use plus Python package via pip

The Bottom Line

This is exactly the kind of unsexy infrastructure work that makes or breaks agent ecosystems. Everyone's building AI agents in isolation; shared contract specs like this are how we avoid a future where every framework has its own proprietary tool-calling format. Worth watching—or contributing to if you care about interoperability standards.