014: Agent/Meta
- Requires:
- Complemented by:
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
: Ameta
message provides the LLM with the identity of the state or process it is currently updating. - In the
schema
: Thesolution
's schema requires ameta
property, compelling the LLM to consider and update the identity as part of its task. - In the
solution
: The LLM generates a newmeta
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.
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
- The principles of autonomous improvement are described in 106: Concept/Evolution.
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.
- This is detailed further in 108: Concept/Visibility.
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 concrete syntax for this addressing scheme is defined in 110: Concept/Addressing.
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
- meta.domain:
-
Reference: A dynamic request for an entity.
idea://my-project.com/bob?1.2
- Search path:
['staging']
- Cutoff date:
2025-10-26T10:00:00Z
(fromcreatedAt
)
-
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
- asked for: latest compatible with
This makes the entire request-solution unit self-describing and addressable.