Early accessInOrbit is opening to software teams, one at a time.
The real-time, programmable engineering coordination platform
Engineering doesn't stop at code.
One workspace for people, AI agents, and the systems they build and operate.
Give agents context and memory. Coordinate their work. Control execution. Verify outcomes with evidence.
- Platform live
- Local agent
- Mac app (invite only)
- Mobile app (invite only)
- Open source
Diagnostics & health
Systems & health
The platform's own components, read from the public status feed every 15 seconds: what runs, how fast it answers, and what needs attention.
5 of 6 measured · 1 needs attention
1 needs attention
ViewSample data · drawn as an illustration
Remember · Keep decisions, results and lessons
Programmable coordination
One state machine every job walks, whether an AI or a person does the work; every step is a gate in Rust that reads evidence.
- There is no call that sets a job's state; a job moves only through its gates.
- A gate that finds something missing holds the job and names it; released, the job returns to the same stage and skips none.
- A wait has a deadline and an escalation: an approval, a runner, a plan window's reset or monitors turning green.
intake → linked → planned → approved → leased → running → checked → merged → rolled → verified → recorded → done
Foundations are what sits under every step of the loop: the policy, guardrails, memory, evidence, agents and coordination that decide what an agent may do before any change ships, so they are the first thing worth knowing.
The platform
Everything in one coordinated workspace.
A set of connected capabilities that turn work, data and decisions into measurable results.
Explore
Turn your work, code and knowledge into a living map.
WorkCodeLiving mapDocsDecisionsMemory
A durable memory of what was said, decided and proven.
- Cache rule recorded
- Hypothesis tested
- Approval recorded
- Fix verified and kept
Planner
Turn goals into plans, steps, and accountable execution.
Our own case study: InOrbit builds InOrbit
Reading our plans…
- Running—
- Waiting on a person—
- Done—
Connecting to the status feed
Canvas
Design, map and reason together with your agents.
InputAgentCheckActionReliability
Monitors, incidents and system health in one place.
- Services—
- Incidents—
- Check runs today—
- Uptime—
Connecting to the status feed
Planner and Reliability show InOrbit's own production, live. The other cards are sample data.
From intent to verified reality
From intent to verified reality.
The strip above is the loop at a glance. Here each step is told in full: what happens, the record it leaves and the evidence behind it.
- 01
Understand
Dataplane and the monitors collect what the system is actually doing, so the work starts from measured facts.
- Record:
- Baseline in production: checkout p95 at 2.4 s, traced to product lookups
- Evidence:
- Monitor runs and the trace of the slow lookups
- 02
Decide
The plan is written in Decisions as a claim, with the test that could prove it wrong. A person reviews it before work starts.
- Record:
- Hypothesis written down: a 60 s cache removes the database call
- Evidence:
- The RFC version and its review
- 03
Coordinate
The Coordinator splits the plan into tasks and starts one agent per task, each in its own worktree, under the team's rules and budget.
- Record:
- Cache change and load test, each to its own agent
- Evidence:
- One job record per task, with the runner it ran on
- 04
Execute
Every change goes through a checked pull request. Policy and guardrails limit what an agent may do, and a person approves the merge.
- Record:
- Pull request behind a flag; a person approved it
- Evidence:
- The pull request, its checks and who approved it
- 05
Verify
Tests run before the release. After it, the monitors compare production with the baseline under the same traffic.
- Record:
- Load test: p95 at 0.6 s. Production after release: p95 at 0.6 s, same traffic shape
- Evidence:
- The load test result and the monitor runs after release
- 06
Learn
What held and what failed becomes a lesson, so the next change starts from it instead of from zero.
- Record:
- Lesson kept: cache only the lookup
- Evidence:
- The lesson, linked to the result that taught it
- 07
Remember
The decision, pull requests, test runs and monitor results stay linked in one record anyone can open later.
- Record:
- Decision, pull request and run linked in one record
- Evidence:
- One record that links everything above
Prove, don't just assume
Proof, impact and evidence in the loop.
Agents can reason, but InOrbit also verifies, measures and keeps a provable record. Below, four of our own, from the pull requests that shipped them.
Hypothesis
TestedWrite the claim down, test it under real conditions, keep the result.
- Claim
- the public status answers in under a second, even when its snapshot has just expired
- Test
- 20 polls of /v1/status, timed; a test that reads past the window against a slow store
- Result
- held: a kept copy is served while one background read renews it
Impact
Measured 2026-11-01Measure what actually improved, with clear numbers and benchmarks.
up to 4.0 s
Both figures are the baseline, measured in production before the change. After: held in tests; production not remeasured yet.
first poll after the window2.8 to 4.0 severy other poll0.18 sMeasured on the public feed on 2026-11-01, before the change. The after is not re-timed in production; the test holds the path.
The public status now: Connecting to the status feed
Evidence Gateway
PolicyLink decisions, changes and results with verifiable evidence.
Traces and metrics
20 polls of /v1/status, 2026-11-01: 0.18 s, then 2.8 to 4.0 s on the first poll after each 24 s window
Pull requests and deployments
core #1551 · merged 2026-11-02
Tests and experiments
status_swr::after_the_window_a_reader_gets_the_kept_copy_and_a_background_read_renews_it
Auditable decision log
RFC 0076 · PRD 0012 · ADR 0170 · Study 0106
Controls & audit
Controls, approvals and a full audit trail.
Typed controls, access and approvals with a trace from decision to code and deployment.
Where we stand
Engineering first
Built for engineers. Open where it matters.
What runs underneath: five parts that do the work, then the ways to build on them.
Dataplane
The agent on your own machines, connecting outbound only. It reports on its host, runs checks inside your network and records what it finds as evidence. Local telemetry is built but not released yet.
InOrbit GatesIn use internally
Build scheduling and CI: one queue for every build, test and release, with checks posted to GitHub. No AI at runtime, so the same inputs always give the same order.
Claude Code and MCP
Decisions, session briefings, lasting memory and guardrails inside the agent tools your team already uses. Each session starts with the team's rules, and anything that needs a yes goes to a person.
Browser Trails
Privacy first. A browser extension records a flow through your site, only with consent: the pages, clicks, timings and browser errors. Never what you type.
CoordinatorAdmins and partners
Joins all of these. It runs agent work under the team's policy, sends each step that needs a yes to a person, and keeps every outcome as evidence you can check.
Self-hosted git runnerComing soon
Run coding jobs on your own machines. The runner checks out the repository, does the work and opens the pull request.
API, CLI and SDK
Integrate with your tools, automate workflows and build your own agents.
Open and extensible
Work with your stack, extend capabilities and keep your data where it belongs.
On the Mac and the phone
The Mac holds the Planner, the Canvas, every approval and the terminal. The phone holds asks, incidents and monitors, and approvals you answer with Face ID. Partners test both before the stores.
Also the iohr command line on macOS and Linux, and the Console in any browser.