Acts of Emergence

014: Agent/Meta

A structured object that holds the explicit identity of a Request, including its name, namespace, version, creation date, and branch associations. It provides a stable, machine-readable anchor for a request's lineage and addressability.

While many agent interactions can be ephemeral, building complex, stateful systems requires a way to uniquely identify and track a Request and its resulting Solution. The Meta object serves this purpose. It is the "business card" of a Request, providing a stable, machine-readable handle that enables persistence, versioning, routing, and historical tracking. Crucially, by making identity an explicit part of the solution, the Meta object empowers the LLM to mint new identities or branch existing ones in direct response to its context, turning a simple response into an act of creation.

The Meta Object in the Request Lifecycle

The Meta object is a first-class citizen in the Request lifecycle. It appears in the context to inform the LLM of the request's current identity, and in the schema as a required part of the solution.

  • In the context: A meta message provides the LLM with the identity of the state or process it is currently updating.
  • In the schema: The solution's schema requires a meta property, compelling the LLM to consider and update the identity as part of its task.
  • In the solution: The LLM generates a new meta object, often with an updated version, reflecting the evolution of the process.

This cycle transforms the LLM from a simple processor into an active participant in the lifecycle of a stateful, versioned entity.

Heads up: From Request to Idea

This entire Request pipeline—the context (including the Meta message), the schema, and the resulting solution—forms a self-contained, reproducible unit. When saved, this unit is what the system refers to as an Idea. The Meta object is the key that transforms an ephemeral Request into a persistent, addressable Idea.

Example Request Structure

// The LLM receives the current meta as context,
// and is tasked to produce a new one in the solution.
{
  "context": [
    {
      "type": "meta",
      "meta": {
        "domain": "reactor.ideas.services",
        "path": "/games/321",
        "version": "1.2.3",
        "branches": ["main"],
        "createdAt": "2025-10-26T10:00:00Z"
      }
    },
    {
      "type": "state",
      "state": {
        "...current game state..."
      }
    }
  ],
  "schema": {
    "type": "object",
    "properties": {
      "meta": {
        "$ref": "MetaSchema"
      },
      "output": {
        "$ref": "GameSchema"
      }
    }
  }
}

Example Solution

// The LLM's solution includes the next game state
// and the bumped version in the new meta object.
{
  "meta": {
    "domain": "reactor.ideas.services",
    "path": "/games/321",
    "version": "1.2.4",
    "branches": ["main"],
    "createdAt": "2025-10-26T10:05:00Z"
  },
  "output": {
    "...next game state..."
  },
  "calls": []
}

Autonomous Evolution and Versioning

A key role of the Meta object is to enable the autonomous evolution of agentic processes. By including the current version and branches in the context and requiring a new version in the solution, the system tasks the LLM with version bumping. Generating a new solution against the same schema is considered a compatible change, and therefore it is imperative that the agent increments the minor version. This creates a new, immutable snapshot of its state and logic, establishing a complete and auditable lineage of the agent's actions over time.

This raises a challenge in distributed systems: if two independent processes react to different events simultaneously, they might both try to bump the version from 1.2.3 to 1.2.4, creating a race condition.

The architecture resolves this using a branching mechanism. When creating a new line of development, a process adds a new branch to the branches array (e.g., ["main", "my-feature"]) and creates a branched version. The versions become 1.2.3.branch-A.1 and 1.2.3.branch-B.1, respectively. This allows for parallel, conflict-free evolution, with the different histories being merged or reconciled later.

Connecting Identity to Address

The fields within the Meta object provide all the necessary components to give a Request a globally unique address. This allows a specific, versioned instance of a request/solution pair to be retrieved, routed, or referenced programmatically.

The resolution process connects a dynamic request to a specific, immutable result. Here is a detailed breakdown:

  • Meta: The properties of a specific, versioned instance.

    • meta.domain: my-project.com
    • meta.path: bob
    • meta.version: 1.2.staging.1
    • meta.branches: ['staging']
    • meta.createdAt: 2025-10-26T10:00:00Z
  • Reference: A dynamic request for an entity.

    • idea://my-project.com/bob?1.2
    • Search path: ['staging']
    • Cutoff date: 2025-10-26T10:00:00Z (from createdAt)
  • Resolved: The permanent, unambiguous URI pointing to the exact resource found.

    • idea://my-project.com/~:staging/bob?1.2:1.2.staging.1
    • Branch: ~:staging
      • asked for: any branch in the search path
      • got: staging
    • Version: 1.2:1.2.staging.1
      • asked for: latest compatible with 1.2
      • got: 1.2.staging.1

This makes the entire request-solution unit self-describing and addressable.