00 Open source · Free · Runs on your computer
Build your AI workforce, under contract.
We're building the AI workforce — and giving it what a workforce needs: an identity, a contract, and a boss. foxora runtime is where you put it to work: every agent with a budget it can't break, permission it has to ask for, and proof it has to show.
Give an agent a job and a spending limit. It does the work, stops to ask before anything risky, and can't say "done" until it shows you the evidence.
One command · Every major model · Nothing leaves your machine
would exceed the ceiling — so it never happened
FXR-0001 · SHA-256 · SIGNED
Every state on this receipt is one the engine really has. The record itself is an illustration — not live data.
all enforced, none optional
each one named
run them yourself
check devtools
[01] Why AI work still feels complicated
AI tools are powerful. Keeping the whole job together is still hard.
Claude, ChatGPT and other AI tools can already research, write, code and act. The challenge begins when one job needs several models, agents, apps, schedules, memories and rules.
- 01The wrong model
- 02Every agent role
- 03Too many apps
- 04Repeating yourself
- 05No clear limits
- 06Changed instructions
-
01
Problem 01 of 06
Using the wrong model for the job.
Different parts of a job need different strengths.
AI tools already offer several models and specialist agents. But when one job moves across tools, you still choose what handles each part, when to switch and when a lower-cost model is enough.
With foxora Give each part to a model that fits.foxora coordinates the models you connect, following the choices and spending limit you set.
-
02
Problem 02 of 06
Building every agent role yourself.
A useful AI team needs clear roles and a clear order.
AI tools can create specialist agents, but you still define every role, write its instructions and decide how the work moves from one agent to the next.
With foxora Start with a team that knows who does what.foxora includes 21 ready-made agents for different jobs. Use them as they are or adjust them for your work.
-
03
Problem 03 of 06
Using too many apps for one job.
Tasks, queues, schedules and approvals rarely stay together.
A plan may begin in chat, tasks move into Jira, schedules live in a calendar and the agent queue sits somewhere else. You spend time copying updates and checking what is waiting, running or finished.
With foxora See and manage the whole job in one place.foxora brings the plan, task order, schedule, approvals and progress into one view while staying connected to the tools you need.
-
foxora helps organise those moving parts while you keep using the tools you prefer.
-
04
Problem 04 of 06
Repeating yourself in every AI app.
Each tool remembers its own conversation.
Claude may know one part of the story, ChatGPT another and Hermes something else. Repeating the same background takes time, and important details can change or disappear along the way.
With foxora Let connected apps use the same shared memory.Add information once, keep where it came from and make it available only to the tools you choose.
-
05
Problem 05 of 06
Starting AI work without clear limits.
The owner, goal, access and budget should never be guesswork.
The owner, goal, allowed access and spending limit are often mixed into long instructions or stored in different settings. As the work continues, those limits can be forgotten and the job can drift.
With foxora Begin every job with clear limits.foxora keeps the person, goal, access and budget with the job, then uses them to decide what may continue and when approval is needed.
-
06
Problem 06 of 06
Changed instructions can go unnoticed.
A webpage, tool or another agent can quietly change the job.
Harmful instructions can appear while an agent is working. If their source is not checked, the agent may change direction, use access it should not use or report the wrong result.
With foxora Check the instruction before the agent acts.foxora checks its source, keeps access within the job’s limits, pauses when something looks wrong and records what happened.
foxora works with the AI tools you already use. The technical safeguards stay behind the simple experience.
[02] What you get
Everything your agents need, in one place.
Build them, run them, watch them — on your own machine, under your own rules.
Connect
Your tools, your data and every major model. Your agents act through them.
Your tools · your data · every major modelRemember
Memory that keeps where every fact came from — and quarantines anything it shouldn't trust.
Source kept · quarantinedBuild
A crew or a whole workforce. Describe it in plain words, or write it in code.
Plain words · or codeWatch
One board for every job. Live state, real cost, and a signed receipt for each step.
Live state · real cost · signed receipt[03] Using it
You set the terms. It does the work.
Three steps. Nothing to learn, nothing to wire up first. What you agree to is the whole interface.
Articles of governed autonomy
Made between the operator, of the first part, and the engine, of the second
Tell it the outcome, what it may spend, and when you need it. That's not a prompt — it's an agreement, and it survives you closing the laptop.
It runs on its own inside your limits, and stops to ask before anything it can't undo. Ask for more than you allowed and it says no — and tells you why.
It can't call the job done until it shows evidence you can open — plus an itemised list of what it did and what it cost. No proof, no "done".
[04] Under the hood
What happens when you give it a job.
Six checks between "do this" and "done". The engine enforces every one, and every one lands on the receipt. The small code under each is what engineers can search for.
FOXORA RUNTIME · the run, as it prints
Intent
Agree what finished means, what it may cost, and when it is due — before anyone starts.
A durable contract carrying acceptance criteria, a four-axis budget and a deadline. INTENT_STATUS_ACTIVE
Admission
Work starts when it is allowed to, not when something asks.
Work waits in a governed queue behind ten named gates. MissionBlockReason
Lease
One job's worth of access, and never more than it started with.
A short hold that can only narrow, scoped to one Intent and a fixed set of actions. COMMITMENT_STATUS_LEASED
Waitpoint
When a job needs sign-off, it stops there until someone gives it.
A raised waitpoint suspends the mission until a named person decides. WAITPOINT_REASON_KIND_HUMAN_APPROVAL
Evidence
Being shown the finished kitchen, not a text saying “done.”
Settlement refuses until criterion codes bind to artifact digests. SETTLEMENT_EVIDENCE_REQUIRED
Receipt
An itemised invoice for the thinking, not just the result.
Each reasoning turn is admitted to the ledger as a signed receipt. AdmitSettlementLearningCommand
[05] Why it's different
Most "agents" are L2 in an L5 costume.
Borrowed from self-driving cars: five levels of how much a machine does on its own. Everyone sells level five. Almost everything shipping is level two or three with a confident voice.
foxora is built for L5 with a boss. Full autonomy inside limits it cannot raise on itself. Hit the ceiling and it escalates to you — it never quietly upgrades its own budget, its own model tier, or its own reach. One lead owns every outcome and answers for it.
Each level below is an endorsement on the licence. Most products carry the first three. The fifth is only safe because of the condition printed beside it.
- L1SuggestsWrites you a draft. You do the work.✓
- L2Acts onceCalls one tool when you ask it to.✓
- L3Runs a taskA few steps while you watch every one.most tools stop here
- L4Runs a laneA narrow job end to end, inside a script someone wrote.✓
- L5Owns the outcomeTakes the whole job and only stops when it genuinely needs a person.conditional
Ceiling set by the holder's operator — budget, model tier, reach. The holder cannot raise it. Reaching it escalates to a person; it never self-upgrades.
[06] Install
One command. Your machine. Nothing leaves it.
One command checks your machine, creates its own keys, starts everything and opens the console. It touches none of your files, and nothing is sent to us — ever.
foxora / install macOS · Linux · Windows via WSL2 · Intel or Apple silicon
sh install
$curl -fsSL https://get.foxora.dev | sh
†[not live yet] get.foxora.dev goes live with the first tagged release. Until then, clone the repository and start at step 02.
Needs Docker and the Compose plugin. It writes only ~/.foxora and ~/.local/bin.
foxora / boot one engine + one Postgres
sh run
$→checking Docker and Compose
✓Docker ready
→generating this machine's keys and certificates
✓written to ~/.foxora
→starting engine, database, gateways
✓console at http://localhost:58080
runs on Docker · Render · Fly · Railway · DigitalOcean · Your laptop
[07] The ecosystem
Not a framework. The whole system.
foxora runtimen. one install that gives your AI workers somewhere to work — and a set of rules they cannot talk their way out of.
Most "agent frameworks" hand you one piece and leave you to build the rest. foxora runtime ships all of it — the app, the engine, the agents, the tools — plus the one layer nobody else does: governance. Everything a real, autonomous crew needs, in one install.
Fourteen parts · one install10 shipped · 4 building
- 01Dashboardshipped
- 02Analyticsbuilding
- 03Engineshipped
- 04Agentsshipped
- 05Toolkitshipped
- 06Triggersshipped
- 07Durabilityshipped
- 08Governanceshipped
- 09SDKshipped
- 10APIsshipped
- 11MCPshipped
- 12Pluginsbuilding
- 13Channelsbuilding
- 14L5 Crewbuilding
= foxora runtime
Build a crew, or a whole workforce
One lead who owns the outcome. Specialists who each carry their own limit. Describe it in plain words, or write it like ordinary code.
- Agents that hold the goal across a whole job, not just one chat
- Exactly one lead answers for the result — the engine checks
validated on publish — exactly one lead, every role capped
Toolkit
Memory, workflows, retrieval, evals and MCP — the tools your agents act through, and the memory they reason over.
- Memory that remembers where every fact came from
- Anything untrusted is quarantined before an agent can read it
nothing read is believed until something vouches for it
Automation & Triggers
Schedules, webhooks and events start work on their own. A job doesn't need you at a keyboard to begin.
- Runs on a schedule, or when something happens
- Work that starts by itself still passes every check
a trigger is not a permission
Durable Execution
Work survives crashes, restarts, deploys — and the weekend. A failed step retries; it doesn't take the job down with it.
- Every job's state lives in the database, not in memory
- A crash resumes exactly where it stopped
the process died at 02:14 — the job did not
Governance
The part nobody else ships. A budget that can't be broken, permission that only shrinks, approvals that actually stop things, and a signed receipt for everything.
- The charge that would break the budget never happens
- Every step signed, so "done" is checkable
would pass the $12.00 ceiling — so it never happened
One install. One database. Fourteen parts that are the same thing — not fourteen integrations you maintain.
Scale 1:1 · Sheet 07[08] The console
See what's running, what's stuck, and what needs you.
One board for every job. Five columns, and each one is a real state the engine is in — not a label someone dragged a card into. Watch the live card walk through its life.
Admitted. Dependencies met, budget held.
Leased to a worker.
Nothing proceeds until you decide.
Closed on evidence.
Failed or escalated, with the reason.
You can't drag a card to "done". The engine decides when work moves, based on the rules you set — a drag handle would promise a power nobody has. The board is an illustration of real states, not live data.
Fig. 08 · Mission board — localhost:58080[09] Every refusal has a name
When it stops, it tells you why.
When an agent stops, it should be able to say why. foxora has exactly ten reasons it can say no — each one named, each with a plain explanation and what to do about it. Never a silent failure, never a log line you have to go hunting for.
Table 08 — MissionBlockReason · closed set
The identifiers live in attention.proto — grep for MissionBlockReason and count them yourself.
DEPENDENCY
Waiting on another commitment this one depends on.
→Settle the dependency, or drop it from the plan.
NOT_BEFORE
The commitment names a time that has not arrived yet.
→Wait, or move the not-before earlier.
LEASED
Already held by a worker under an active lease.
→Wait for the lease to expire or resolve.
TERMINAL
The commitment already failed or completed.
→Nothing to do — read the settlement.
BUDGET
refused in the same transaction as the charge
Would push consumed spend past a limit on some axis.
→Raise the limit on that axis, or spend less.
ADMISSION_LIMIT
The mission or org is at its concurrent-lease ceiling.
→Wait for a lease to free, or raise the ceiling.
RECOVERY
The Intent is paused under RECOVERY_ONLY pressure.
→Resolve the pressure the self-model flagged.
COUNTERFACTUAL
Foresight scored this ALTERNATIVE or NO_ACTION.
→Review the branch evaluation before forcing it.
OPERATIONAL_READINESS
A dependency the self-model tracks is not healthy.
→Clear the deficit the self-model named.
HOMEOSTASIS
System-wide pressure is above NORMAL for this Intent.
→Wait for pressure to clear, or raise it by hand.
[10] Spend
Same work. Half the bill.
foxora sends each step only what it needs, and routes it to the cheapest model that's good enough for that step. The same job costs 50–60% less than running all of it on OpenAI, Claude or another frontier model. And a hard ceiling means the bill can never surprise you.
Where this goes: agents that don't depend on frontier models at all. Each agent chooses the model for each piece of work itself — the most efficient one that clears the bar, and the cheapest — including small models built for the job.
Four limits — money, words in, words out, time — and every one is enforced by the engine, not by a warning email after the invoice. Fig. C · intent budget
[11] What can be checked
Nobody has said anything about foxora yet. Here is what you can check instead.
No customer quotes, no logos, no adoption numbers — there are none, and inventing them would be the first thing this project claims to prevent. Everything below is a fact you can verify yourself in the time it takes to clone the repository.
- 010 crates in the open the whole engine, Apache 2.0 — not a demo of it
- 020
tests you can run
cargo test— the count of test functions incrates/ - 030
protocol contracts
every boundary in
contracts/proto, written down before the code - 040 decision records why each choice was made, including the ones that were wrong
- 050 bytes sent to us open DevTools ▸ Network on this page and watch
Drafts · sent for approval, none confirmed
“It stops when it says it will stop. That turns out to be the whole thing.”
Fran · [role]
“It waits. That sounds small until you’ve had something not wait.”
Andy · [role]
“It runs on our own machines and sends nothing anywhere. That was the end of a much longer conversation with our security people than I expected to have.”
Royal · [role]
“What I care about is being able to reconstruct, afterwards, why a system did what it did. This is the first agent runtime I’ve seen that treats that as a requirement rather than a feature request.”
Dr. Milo · [role]
Every statement above is a draft written for that person to approve, reject or rewrite — none of them has said these words yet. Each becomes a real statement only when its subject confirms it in writing, and the counter above stays at zero until then.