Agents
An agent is a skill that runs in Claude against your project, through the XCubes connector, and whose only output is a set of proposals. It never writes a cube cell. You approve what it proposed; a Link carries the approved rows into the cube; a revert takes them back out. That is the whole contract, and every shipped agent follows it.
What an agent may and may not do
Every agent ships with a scope: the cubes it reads, the proposals table it writes, the Link that applies approved rows, and the tools its key is allowed to call. Installing it on a project resolves that scope against your objects — the install dialog says which cube it will read and what is missing — and mints nothing on its own.
An agent:
- reads the cubes in its scope and cites, on every row, the cells it read (the Source Cells column), so lineage runs both ways;
- writes rows to its proposals table only, through
add_proposals, inside a run it opened withstart_agent_runand closes withend_agent_run; - never calls
set_cube_data, never runs or reverts a Link, and never approves or edits a proposal — those tools are not in its key's scope, so the server refuses them before anything is read; - stops on a failing precondition (no data in the period, a check row not zero) and reports it in the run's outcome rather than proposing on bad inputs.
What a proposal is
A proposals table is a data table of kind proposals: it carries built-in columns nobody can remove — Proposal (the group id: the legs of one journal entry share it), Status, Author, Run, Reason, Source Cells, Flag, Reviewed By, Reviewed At — plus the dimension and value columns that address the cube. Every row an agent writes lands PROPOSED with the agent as Author and its run id in Run.
Flag is where the agent says it is unsure: FX when two sides translate
to different amounts, TIMING when a counterpart sits in a neighbouring
period, UNMATCHED when one side has no counterpart. A blank flag means a
clean proposal, which is what "Approve all clean" approves in one click.
Statuses
| Status | Set by | Meaning |
|---|---|---|
| PROPOSED | the agent (or a person) | Waiting for review |
| APPROVED | a reviewer | The next Link run will apply it |
| APPLIED | the Link run | Its value is in the cube; the row is read-only |
| REJECTED | a reviewer | Withdrawn; an applied value clears on the next Link run |
| REVERTED | a Link revert | The value was taken back out of the cube |
A Link on a proposals table reads only APPROVED rows — the filter is forced, not configurable — so nothing reaches a cube without a person having said yes. The table editor's review bar and the project's Review queue (Agents tab) are the two places to say it.
Runs
Every run is logged: which agent, which key, when it started and ended, its outcome, how many rows it proposed, and what became of them. A run left open for more than a day reads as abandoned, and its rows carry that warning in the review queue — half a journal from an agent that crashed is visible as such, not mistaken for a finished one. The agent's page in the Agents tab lists the runs; each opens to its proposals and to the Link executions that applied them.
Running an agent
From the agent's page, Run first makes sure you hold a key minted for that agent and that project — the key's scope is the agent's tool list and nothing else — then hands the work to Claude: Open in Claude starts a chat with the run prompt, Copy prompt is for Claude Code, Cowork or any MCP client. The key is never part of the link; the connector you configured with it does the work.
Custom agents
The shipped agents are bundles of a skill, a scope and a proposals-table shape. A skill forked into your own MCP client's skill folder can follow the same contract — open a run, propose, close the run — with a key you scope by hand in Settings → API keys → Restrict this key. Registering a custom agent in the gallery is not in the product yet.