Orientation
01RunLedger keeps important work from getting lost.
When a Connector gathers a lot of information, a single conversation can become too full to carry every result safely into the next step.
RunLedger keeps that gathered information in a separate, controlled work record. Your assistant can summarize or continue a long conversation, then come back to the same verified work instead of starting over or guessing what was collected. It is not a source-system Connector or a reporting tool. It is the reliable handoff point between those parts of the work.
How it fits
02Use it when collection is bigger than one conversation.
Collect a lot of information without making the conversation carry it all
Ask your other Connectors for information in manageable pieces. RunLedger saves each piece to the work record as it arrives. Your assistant can then move on, summarize the conversation, or return later without forgetting what the workflow already collected.
Token efficiency: RunLedger saves conversation space. The assistant does not need to repeatedly carry long source responses forward or collect the same information again just to recover from a summary or a pause.
| Without RunLedger | With RunLedger |
|---|---|
| The conversation has to remember every collected result. | Collected results live in the run, outside the conversation. |
| A long conversation or summary can lose earlier detail. | The workflow continues from the same checked collection. |
| The final output may be created from partial information. | The next phase uses a verified handoff only. |
| Each workflow can invent a different definition of complete. | The recipe gives every run the same definition of complete. |
What does RunLedger keep?
It keeps the collected pieces, the checks that confirm they are ready, and a record of the final handoff. It reports progress using counts and identifiers rather than displaying the stored information in routine status updates.
RunLedger controls the handoff, not the source systems
What stays protected. RunLedger does not accept sign-in information in workflow data, does not let a request point to files on a machine, and does not tell a workflow that work is ready until the agreed checks pass.
What is registration-only access?
Before normal sign-in is enabled, an MCP client can inspect RunLedger’s Connector description for registration. It cannot collect, change, or retrieve workflow information. Normal use begins only after authenticated access is configured.
In depth: implementation and Connector reference
This tab is for workflow designers and technical implementers. It explains the setup that happens once for a repeatable workflow, then supports many everyday runs.
Connector endpoint URL: use this fully qualified address only in a Connector setup form or configuration:
This Connector’s address will appear here.
How information moves through a RunLedger workflow
The workflow decides where this stored work lives when it is set up. The user chooses one of the approved modes; RunLedger never accepts a user-supplied path or database connection.
Local filesystem mode
Use this for a private or local workflow running through the local RunLedger Connector. The workflow names an approved local state location at setup time.
Shared MongoDB mode
Use this for a deployed team Connector. The workflow uses a permitted work area, while the deployed service connects to its approved MongoDB backing.
What is a recipe, and who creates it?
A recipe is the reusable collection plan for one workflow. A workflow builder creates it once before regular use. It defines what information is expected, which fields are allowed, how duplicate items are handled, and what must be present before the next phase can begin.
Keep this block in the workflow or skill that starts the work. The workflow passes the same recipe when it starts each run, and RunLedger automatically saves an unchanged copy with that run.
Tool reference: names and responsibilities
list_workspaces- Shows the work areas the signed-in person may use.
create_workspaceandgrant_workspace_access- Administrator tools for creating a work area and giving people reader, writer, or administrator access.
start_run- Begins one instance of a workflow using its recipe and selected work area.
stage_batch- Adds one manageable collected result to the run.
finalize_collectionandstage_artifact- Prepare the collected information and required handoff item for checking.
validate_runandrun_status- Confirm whether the run is ready and show what still needs to happen.
cleanup_run- Removes temporary collected pieces only after validation succeeds, while retaining the verified handoff record.
Start here
03Build one skill with one RunLedger handling block.
The workflow builder adds this once. The person using the skill then asks for the outcome in plain language.
Add the following block inside the same skill that gathers task updates and writes the final list. It is not a second skill or a separate prompt for the user.
This is the workflow’s reusable recipe in practical terms. Keep it in the skill instructions. Every time the skill starts a run, RunLedger receives this plan and automatically saves an unchanged copy with that run.
“Create this week’s team to-do list.”
- The skill selects a permitted work area and starts a RunLedger run using the embedded recipe.
- The skill gathers task updates through its source Connector and gives each result to RunLedger.
- RunLedger checks the collection and creates the verified handoff.
- The skill writes the final list from that verified handoff, not from whatever happens to remain in the conversation.
After this small version works, replace “task” with the records your real workflow needs to collect. Keep the same one-skill, one-recipe, verified-handoff pattern.