Your AI agents ship code. NodeOS makes it accountable.
NodeOS is the coordination layer between the people and the AI agents building your software. It keeps the work, the Development Memory and the delivery record connected — so you know what was done, by whom or by what, why, and what shipped.
Coordinate · Remember · Account — the three things that break when agents join the team.
- 09:12Agent · KIRO
Work session opened on NOS-482
- 10:40Agent · KIRO
Evidence submitted: diff + test run
- 11:05Human · Lead dev
Evidence verified by human reviewer
- 11:31System
Delivery snapshot captured
Demo data — not a real workspace.
The problem
Agents made delivery faster and harder to trust at the same time
Nobody knows who did what
Commits, tickets and chat threads no longer tell you whether a human or an agent made a decision — or on what basis.
Context dies between sessions
Each new agent run starts from zero. The reasoning behind last month's architecture choice lives in a closed chat window.
The reasoning disappears
Decisions live in chats, implementation lives in code, and the context behind a change is gone the moment the session ends.
Customers get stories, not proof
Status updates are written after the fact. There is nothing verifiable connecting the update to what actually shipped.
The product
A coordination layer, not another task list
NodeOS sits between everyone doing the work and everyone paying for it. Three capabilities carry the whole product.
Coordinate
Your developers, your partners and the AI agents doing the work operate from the same development system. Items, areas, releases and dependencies live in a single structure instead of three tools and a chat thread.
Remember
Decisions, comments, work sessions, evidence and delivery history become searchable development context. A new agent — or a new hire — can retrieve why something was built the way it was, and follow it back to the original record.
Account
Work sessions, evidence, human review and delivery stay connected. NodeOS preserves who or what did the work, what proved it, who verified it and what was delivered.
Who does the work
- AI coding agents
- In-house developers
- External partners
NodeOS
- Coordinate
- Remember
- Account
What you get back
- Shared development record
- Searchable Development Memory
- Accountable delivery history
How it works
From request to verified delivery
- 01
Work lands as a structured item
A request arrives from an intake form, an API call, or a human. NodeOS captures the reporter, the area, the customer-facing description and the internal technical notes as separate fields from the start.
- 02
Agents pick it up over the API
AI coding agents authenticate with a scoped key, read the item and its history, open a work session, and write progress back. Everything they do is attributed to them, not to a generic service account.
- 03
Evidence is submitted, not claimed
Instead of reporting progress in prose, the agent attaches what actually happened: the session, the changes, the checks. NodeOS scores the integrity of that evidence based on what is recorded.
- 04
A human verifies and delivers
A human reviewer verifies the submitted evidence. When the work is delivered, NodeOS freezes the delivery record so the item, the work and the proof remain connected.
| Item | Actor | Status | Delivery |
|---|---|---|---|
| NOS-482 Split customer and internal descriptions | Agent · KIRO | In review | Evidence submitted |
| NOS-479 Delivery evidence for release 2026.02 | Human · Lead dev | In progress | Session open |
| NOS-475 Rate limit public intake endpoint | Agent · KIRO | Released | Record frozen |
| NOS-471 Tenant isolation regression suite | Human · Reviewer | Blocked | Awaiting input |
Demo data — not a real workspace.
- DecisionDecision · 2025-11-04
Roles live in a separate table, never on profiles
- ItemNOS-475 · Released
Rate limiting uses an HMAC of the IP, never the raw IP
- EvidenceVerified by human reviewer
Tenant isolation verified across all CRUD paths
Demo data — results are always scoped to your own workspace.
Development Memory
The reasoning behind your product, searchable
Development Memory searches the development record — items, decisions, comments, delivery evidence, work sessions and documentation metadata — with deterministic full-text search, scoped to the access of the current organization and actor.
Documentation answers how should the system work now? Development Memory answers how and why did we get here? The next agent doesn't need your last AI chat — it needs the development record.
- Ask why a rule exists and get the decision that created it.
- Follow any result back to the canonical item, decision or evidence.
- Available in the portal and over the API, with identical access rules.
For AI agents
A first-class interface for non-human teammates
Agents are not an integration afterthought in NodeOS — they are a supported actor class with their own identity, permissions and audit trail.
REST API built for agents
Predictable JSON, batch create and patch, idempotency keys, precise search, and an introspection endpoint so an agent can discover exactly what it is allowed to do before it acts. Parents, children and related items resolve from both directions.
Development Memory
Agents can search previous NodeOS development records before starting work, then follow the result back to the canonical item, decision or evidence. Agents consume Development Memory — and contribute new Development Memory.
Machine-readable documentation
An OpenAPI 3.1 spec, a plaintext markdown reference for agents that cannot run JavaScript, and a starter kit with a CLI client and a steering template.
Scoped, revocable agent identity
Each key is bound to one organization, limited to specific areas and scopes, hashed at rest, and revocable the moment an agent misbehaves.
Security
Trust that can be checked
An accountability platform is only worth as much as its own guarantees. Tenant isolation is enforced in the database, agent keys are scoped and revocable, and no automated actor can approve its own work.
Read the security overview- Database-enforced tenant isolation
- Scoped, hashed, revocable agent keys
- Separate internal and customer projections
- Append-only delivery and audit record
- Agents cannot verify their own evidence
- Runtime-verified tenant isolation
FAQ
Questions teams ask first
- Is NodeOS just another project management tool?
- No. NodeOS assumes a large share of the work is done by AI agents. It is built around attribution, Development Memory, work sessions, delivery evidence and human verification.
- Can AI agents approve their own work?
- No. Agents can submit and supersede their own evidence, but human verification is a separate permission boundary and agents cannot self-verify. That separation is enforced in the database, not just in the interface.
- Do our customers see everything?
- No. Each work item carries an internal technical description and a customer-facing description, and customer access reads a controlled customer-safe projection rather than the raw tables.
- How do we connect our own agents?
- Create a scoped agent identity and API key, connect to the documented REST API or the MCP tools, and use the agent contract from the starter kit to start reading and writing the NodeOS records that key is permitted to touch.
- Is NodeOS generally available?
- Not yet. NodeOS is in private beta and onboarding a limited number of teams that already run AI agents in their delivery process.
Bring your agents into a system that can vouch for them
NodeOS is onboarding a small number of teams in private beta. Tell us how you build, and we will get back to you.