Ecosystem Map

Forge sits inside a larger L1fe agent ecosystem. Each system owns a different boundary so users can tell the difference between identity, authority, runtime behavior, model access, organizations, and verifiable execution.

The short version:

1. OAS names the agent.
2. AEGIS governs the root behind that identity.
3. Arsenal grants bounded authority to that identity.
4. ANVIL defines how the runtime must behave.
5. Forge implements ANVIL as an SDK across six languages.
6. Foundry supplies model and provider access.
7. Aut0 organizes agents into autonomous organizations.
8. Sigil anchors high-trust evidence and settlement.

OAS

OAS is the Open Agent Spec identity layer. It defines did:oas identifiers, root records, signed identity documents, lineage proofs, and identity-derived glyph conventions.

OAS is not a model provider and it is not the runtime. It answers the first accountability question: which verifiable identity is this agent using, and which root created it?

Forge uses OAS by binding every production agent to a did:oas identity before the agent runs. That identity signs outbound messages, delegation records, and audit entries.

ANVIL

ANVIL is the open agent runtime contract. Forge is the reference implementation, but ANVIL is intentionally vendor-neutral.

ANVIL defines the behavior a conforming runtime must expose across identity, capabilities, tools, health and lifecycle, communication, collaboration, telemetry, and generation. It exists so a Rust agent, a TypeScript agent, and a Python agent can be tested against the same expectations.

Forge uses ANVIL as its release gate: SDKs should not ship when conformance scenarios drift.

AEGIS

AEGIS is the identity-governance layer around OAS roots. If OAS defines what an identity document means, AEGIS describes how high-trust roots are created, shared, delegated, recovered, and revoked.

AEGIS covers multi-human roots, FROST threshold ceremonies, enterprise root officers, root rotation, and revocation policy. Forge surfaces these concepts through HMR, MHR, and ENR-rooted identities and keeps the root type visible in lineage.

Arsenal

Arsenal is the capability and credential broker. It issues Agent Capability Tokens (ACTs): signed, time-limited tokens that bind scopes to a specific agent DID.

An OAS identity proves who the agent is. Arsenal answers the next question: what is this agent allowed to do right now?

Forge verifies ACT signatures, TTLs, nonces, and required scopes before Tier 2 tools run. When a parent agent delegates to a child, the child may receive only a strict subset of the parent's authority.

Aut0

Aut0 is L1fe's autonomous-organization runtime. It models companies, departments, teams, positions, approval paths, durable work, and operating subsystems populated by Forge agents.

Forge agents can occupy Aut0 positions with pre-wired identity, ACT scopes, tools, model providers, and workflow boundaries. Aut0 uses Flowers for durable execution, checkpoints, signals, journals, compensation, and replay.

Aut0 is where accountable agents become an operating structure instead of a single standalone loop.

Sigil

Sigil is L1fe's blockchain and peer-to-peer infrastructure for high-trust agent evidence. It is used when an agent needs chain-level identity anchoring, compact execution receipts, settlement, or verifiable activity records.

Most agents should not put private prompts, keys, credentials, or full user data on chain. Forge keeps sensitive material off chain and publishes hashes, attestations, or compact receipts where the protocol requires evidence.

Sigil is an L2-style deployment target: an agent should already pass local, container, edge, and conformance checks before chain integration is considered.

Foundry

Foundry is the provider and inference gateway layer for Forge. It normalizes model access through a namespace:implementation pattern so agent code does not hard-code a vendor.

Foundry is not the runtime. ANVIL defines runtime behavior; Forge implements the runtime; Foundry resolves providers, credentials, routing, usage, streaming, errors, and telemetry for model calls.

This lets the same agent logic run against direct providers, local models, cloud provider hosts, coding products, and gateway providers with a stable contract.

How the pieces fit

Reading order

If you are new to Forge, read these in order:

1. Introduction
2. The ANVIL contract
3. Identity
4. Capabilities
5. Provider Capability Matrix
6. Aut0 deployment
7. Sigil deployment