XCT — Execution Control Transfer
A protocol we built because we got tired of LLMs doing things they shouldn't. Models propose, systems validate, tools execute. That's it. No magic — just separation of concerns applied to AI.
Why We Built This
Most AI integrations let the model run the show. That works fine until it doesn't — and in production, "doesn't" can mean deleted infrastructure, wrong transactions, or silent data corruption.
The Usual Approach
- Model decides what to do and does it
- Tools are just extensions of the model's will
- State changes happen without explicit validation
- Failures are unpredictable and hard to trace
- Good luck with the audit trail
What XCT Does Instead
- Model suggests an action, nothing more
- System decides whether to approve it
- Tools execute deterministically
- Errors come back as structured data, not exceptions
- Every step is traceable
The Rules
Five constraints. Not features — constraints. XCT works because it limits what the model can do.
No action without a tool call
The model can't describe an action and pretend it happened. If there's no tool invocation, nothing changed. Period.
One step at a time
One proposal per iteration. The system owns the loop — it can pause, inspect, or stop at any point.
The model doesn't remember
Context comes from the system, not from the model's memory. Same input, same output. No hidden state, no surprises.
Errors are data
A failed tool call isn't a crash — it's information. The model gets the error back and proposes accordingly. No retries, no panic.
The system can always say no
Valid syntax doesn't mean approved. The system can veto any proposal for any reason — policy, resources, or just "not now."
How It Works
Two possible responses. That's the whole contract.
Model Output
Propose an action:
{
"next_step": {
"tool": "fs.write",
"arguments": {
"path": "config.yaml",
"content": "..."
},
"goal": "update the config"
}
}Or say "done":
{
"done": true,
"message": "config updated"
}System Response
It worked:
{
"status": "success",
"result": { ... }
}It didn't:
{
"status": "error",
"message": "permission denied"
}"Decision is cheap. Execution is expensive. Keep them separate."
When It Makes Sense
XCT adds overhead. Use it when the cost of getting it wrong is higher than the cost of going slower.
Good Fit
- • Infrastructure automation (deploy, scale, delete)
- • Financial operations and blockchain transactions
- • Document validation in regulated environments
- • Anything where "undo" is expensive or impossible
- • Multi-step pipelines with real-world side effects
Probably Overkill
- • Quick prototypes and experiments
- • Creative writing or brainstorming
- • Chatbots and conversational UIs
- • Simple question/answer patterns
- • Low-stakes internal tooling
Want to try it?
XCT is open-source. Read the spec, check the implementations, or reach out if you want to talk about how it fits your stack.