Skip to main content
Incillum
Join early access

Work · JANUS

JANUS is a hackathon build, not an Incillum product. It is public, it works, and everything below can be checked by opening it.

An agent that can do the work, and cannot do the deciding.

JANUS rehearses a launch before it happens. It runs three structured futures of the same launch, names what they have in common, and helps prepare a response — and it hands a browser agent the same typed actions a person uses for all of it, except the one that matters.

Open the demoBest in a browser with native WebMCP. Everything works by hand without it.

What it does

Three ways the same launch could go.

Somebody describes a launch as a set of assumptions — expected visitors, target conversion, how ready checkout is, who is covering support, how much trust the brand has. JANUS runs three futures of that launch and shows what happens in each, why it happens, and what the first visible sign would be.

Upside
Demand arrives and the operation holds. The constraint moves to the support desk before it moves anywhere else.
Drift
The launch works and then quietly stops mattering. Signups look healthy; nobody builds a reason to come back in week two.
Breakdown
One operational weakness compounds into a public one. Payment retries become duplicate charges, then a support queue, then a conversion problem.

At the example launch those come out at 39, 58 and 46 — modelled pressure out of 100, not a probability and not a prediction. Below 40 reads as low, 55 and above as high.

The sequence

Where the line is drawn.

This is the whole argument in one interaction. Every step below is something the software actually does, in the order it does it.

  1. Step 01 Agent

    Reads the launch and runs the three futures

    It calls typed actions the page has published — read the launch, run a future, compare them, trace what causes the breakdown. The three futures appear on screen as it goes.

  2. Step 02 Agent

    Prepares a response, and is refused

    It stages the smallest set of measures that improves more than one future, then asks to verify its own work. Verification is refused: no person has approved anything yet.

  3. Step 03 Person

    Changes one assumption

    Expected visitors go from 20,000 to 80,000. The prepared response immediately desaturates and reads “Needs reassessment” — it was built against a launch that no longer exists.

  4. Step 04 Agent

    Notices, without being told and without a reload

    It reads the launch again, sees the response is no longer valid, runs the futures against the new numbers, and prepares a replacement.

  5. Step 05 Person

    Approves it

    This is the one action no tool can perform. There is no approve, ratify, publish or override action on the agent surface — not disabled, not permission-gated. It is not there.

  6. Step 06 Agent

    Verifies the exact thing that was approved

    It re-runs the model with the approved measures applied and reports pressure before and after. If the plan had changed by one character since approval, verification would fail rather than pass quietly.

Where it stops

The approval is not a permission.

The usual way to keep an agent away from a decision is to give it the capability and then withhold the right. JANUS does not have the capability to withhold. Approval exists only as something a person does in the interface, so there is nothing to misconfigure, nothing to escalate, and nothing that a longer prompt talks its way past.

A plan is bound to the launch it was built against
The measures, the launch state and the reason are hashed together. Change an assumption afterwards and the approval and the verification are both dropped, because they belonged to a launch that no longer exists.
Verification recomputes rather than trusts
It hashes the plan again from the plan’s own contents and compares that against what was approved. A plan edited after approval fails the check instead of riding it through.
Nothing is predicted
Every score, comparison, causal chain and verification comes from plain deterministic code. No model sits in the path that produces a number, so the same inputs always give the same outputs.
A refusal says how to recover
Every failure carries the reason and the next legal action, because an agent that is told only “no” has no way to find out what it should have done.

How it is built

One path, two callers.

A person’s click and an agent’s call land on the same application command, which calls the same engine and writes the same state. There is no second implementation of any rule for the agent — which is why an agent cannot reach a field, like an approval or a revision, that the command does not accept from anybody.

Six typed actions, published to the browser
The page registers them on the browser’s own model-context interface, so a compatible agent finds them by reading the page rather than by being wired to it. They read the launch, run a future, compare the three, trace a cause, prepare a response, and verify an approved one.
Semantic actions, not clicks
Nothing here automates a cursor. The actions mean what a person means, so a change to the interface does not silently change what an agent is doing.
Readiness is checked, not assumed
Registration resolving is not treated as proof. The tools are read back out of the browser and all six must be present before anything reports itself ready; a partial surface is an error that names what is missing.
Agent activity is observed, never narrated
While an agent works, the page shows what it actually did — one line per real call, taken from the record. It shows no reasoning, because it has none to show, and inventing some is the one thing that would make the demonstration a lie.

What was checked

Verified against the deployed site.

The sequence above is not a description of intent. It was run end to end against the public deployment, in a browser, driving the published actions the way an agent would.

114 automated tests
The engine’s arithmetic, the command layer, hashing, the revision rules, the published action surface, and the copy rules.
28 checks against production
The full sequence — six actions, a refused verification, a changed assumption, a recovered plan, a human approval, a passing verification — with no page error and no reload at any point.
Nothing stored, nothing to sign in to
A rehearsal lives in the browser that ran it. There is no account, no database and no server holding anybody’s launch.

JANUS is a small thing built quickly, and it is on this site for one reason: the question it is about — where an autonomous system stops and a person decides — is the same question the rest of this site is about.

Back to Incillum