LIGHTCONE / AGENTS
Was this action allowed, and can you prove it?
Lightcone is a control boundary for autonomous AI. It answers one question that gets harder as agents get more capable: what is this thing allowed to reach, and who said so? Authority is delegated in bounded envelopes that fail closed, every consequential action is checked against an active envelope before it leaves, and the decision is written to a record that cannot be quietly edited afterwards.
The name is from relativity: a light cone is the region an event can causally influence, which is the shape of the question above. Lightcone is one of several systems Kairos Dynamics is building on one rule, that nothing advances toward a consequential action without having proved it should. Invariant applies that rule to a prediction; this applies it to an agent. The two panels below are working, each running the decision procedure the software runs, so pushing on them shows real behaviour rather than a story about it.
Where this actually stands. Lightcone runs, and what is described here is implemented and covered by an automated test suite. It has not been deployed in production by anyone, it has no users, and it has never governed a real agent doing real work. Treat it as research advancing toward a product. Everything below states what the software does, not what it has achieved, because it has not had the chance to achieve anything yet.
The boundary, and what happens at it
Authority is handed over in an envelope: one person's written permission for one agent. Propose an action against it and it answers in one of three ways. Allow it, refuse it, or hold it until a person says yes. An envelope this specific does not come from a sentence: compiling a plain instruction produces a draft that permits more than was intended, so Lightcone asks about the gaps from a fixed list, ordered by how much damage the missing answer could do, blocking activation on the consequential ones. Answers become policy through handlers written in advance. A model may suggest further questions, and that is the whole of its authority: it can ask, and it cannot decide.
What is this agent allowed to reach?
An authority envelope names the tools an agent may use, what it may do and touch, which data it may read, how much it may commit and when the permission runs out. Here is one, with an action proposed against it. Change the action; the answer changes with it.
State of the envelope
A person read this boundary and activated it deliberately. It is the only state permitting anything, and never the state an envelope arrives in.
The action being proposed
Tool it would use
What it would do
What it would touch
Data it would read
Money it would commit
This exact combination is one request, with one identity:
act_00000000
Where it falls against the boundary
Inside, no question asked Inside, but a person is asked Outside
Already committed: $12,000 of $60,000, and 41 of 200 actions. Only the money track is drawn to scale; the other five are categories.
✓Allow
Action is within delegated authority.
Written to the record as within_authority
- APPROVAL
- BOUND TO REQUEST
- STATUS
The record it leaves
Every decision becomes a receipt, kept in order. This is the artefact every system Kairos builds has in common: a record of what was permitted and what was refused, kept rather than discarded. Try to edit it.
Every decision is written down, and the writing is checkable.
A receipt carries a fingerprint of its own contents with the previous one's fingerprint folded in, tying the entries together in order. Select any entry to read it, and to change what it says.
✓Ledger verifies
All four entries match their contents and their place in the order.
What it refuses to do
The useful part of a control system is the list of things it will not let you do, including by accident. These are design decisions rather than settings, so you do not have to configure them correctly to get them.
- Deterministic at the boundary
- The same request against the same envelope produces the same answer. Nothing at the decision point is sampled, inferred or generated.
- Models advise, models do not decide
- A model can help draft an envelope and can be asked to attack one, looking for questions nobody thought of. Its questions are advice. It cannot grant, remove or change what an agent may do.
- Outbound calls are fenced
- Anything sent outside goes through a proxy that checks the boundary first, speaks only to hosts named exactly on an allowlist, refuses anything not HTTPS, and follows no redirect elsewhere.
- Rehearsal costs nothing
- A dry run consumes no spend and no part of the action budget, so a boundary can be tested on real examples before anyone commits to it.
Invariant asks whether a prediction has earned the right to be acted on. Lightcone asks whether an action had the right to be taken. They are not one codebase today, and joining them is a direction rather than a product. Nor are they the company: they are two of the systems built on it, far enough along to describe honestly, and the shape they have in common is the thing worth understanding first.
Join the waitlist to hear when there is something to run, or get in touch if you have an agent doing something expensive and want to talk about boundaries before it does.