014: Agent/Meta
- You'll need to understand this first:
- These documents add more details:
Think of Meta Properties as the official ID card for any request sent to the AI. It’s a neat little package of information that clearly states the request’s name, where it belongs, its version number, when it was made, and what project branches it's part of. This gives every request a permanent, computer-readable identity so it can always be found and understood.
While many conversations with an AI can be quick and forgettable, building something big and complex requires a way to remember and keep track of every step. The Meta
object is like an ID card for each Request and its final Solution. It provides a stable, computer-friendly label that allows the system to save, version, find, and look up the history of any task. What’s really cool is that by making this ID card part of the AI's answer, we let the AI create new ID cards or create new versions of old ones all on its own. This turns a simple answer into a creative act, like starting a new chapter in a book.
The Meta
ID Card in Action
The Meta
object is a VIP in the life of a Request. It shows up to tell the AI what it's working on, and the AI is required to create a new one as part of its answer.
- In the
context
: Ameta
message acts like a sticky note, telling the AI, "Here is the ID for the thing you are currently working on." - In the
schema
: The rules for the answer require ameta
section, forcing the AI to think about the task's identity and update it. - In the
solution
: The AI creates a brand newmeta
object in its answer, usually with an updated version number, showing how the task has progressed.
This process changes the AI from being just a tool that follows instructions into an active partner that helps manage the history of a project.
This whole package—the context
(including the Meta
ID card), the schema
(the rules), and the final solution
—is a complete, repeatable unit of work. When you save this unit, the system calls it an Idea. The Meta
object is the magic key that turns a temporary Request
into a permanent, findable Idea
.
Example of a Request
// The AI gets the current ID card (meta)
// and is told to create a new one in its answer.
{
"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 of a Solution
// The AI's answer includes the next game step
// and a new, updated ID card with a new version.
{
"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": []
}
Growing and Versioning on Its Own
- You can read more about how things improve on their own in 106: Concept/Evolution.
A key job for the Meta
object is to let the AI's work evolve automatically. By telling the AI the current version and requiring it to create a new one in its answer, the system gives the AI the job of tracking versions. When the AI creates a new answer, it's like writing the next page in a book, so it must update the version number (like from page 2 to page 3). This creates a permanent, unchangeable snapshot of its work, building a perfect, traceable history of everything the AI has done over time.
But what happens if two AIs try to do this at the same time? Imagine two authors both trying to write Chapter 4 for the same book at the exact same moment. They might overwrite each other's work!
- For more on this, see 108: Concept/Visibility.
The system solves this by letting them create different "branches," or alternate timelines. Instead of both creating version 1.2.4
, one can create 1.2.3.branch-A.1
and the other can create 1.2.3.branch-B.1
. This lets them work at the same time without getting in each other's way. Later, their different chapters can be reviewed and combined.
Connecting an ID to an Address
- The exact rules for how these addresses are written are explained in 110: Concept/Addressing.
The information inside the Meta
object gives every Request a unique address, like a postal address for a specific letter. This lets anyone in the system find, send, or refer to an exact, versioned piece of work.
This process connects a general question to a specific, permanent answer. Here's how it works:
-
Meta (The ID Card): The specific details of one saved answer.
- 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 (The Question): A general request for something.
idea://my-project.com/bob?1.2
(I want the latest version of 'bob' that starts with '1.2')- Search path:
['staging']
(Look in the 'staging' branch first) - Cutoff date:
2025-10-26T10:00:00Z
(Don't look for anything created after this time)
-
Resolved (The Answer): The permanent, exact web address pointing to the result that was found.
idea://my-project.com/~:staging/bob?1.2:1.2.staging.1
- Branch:
~:staging
- You asked for: any version in the 'staging' branch.
- You got: the one in the
staging
branch.
- Version:
1.2:1.2.staging.1
- You asked for: the latest thing that matches
1.2
. - You got: version
1.2.staging.1
.
- You asked for: the latest thing that matches
This system makes every piece of work easy to describe and find, just by looking at its ID card.