A development suite for AI agents: project management, engineering memory and orchestration.
PROJECTAI Development Platform
MY ROLEFounder & Software Engineer
STAGEIn my own daily use · deeper integration in development
The Record’s workspace home. A local run of the product’s own code with invented projects and people; real client pages stay private.
The context
A problem worth solving.
AI-assisted work can lose context across sessions and scatter decisions across repositories, conversations and tools. Planning and delivery need a shared structure that humans can inspect.
My contribution
What I brought to the work.
Built an internal product suite around three responsibilities: managing the work, retaining engineering knowledge and supervising agent assignments. These tools run my own development process and the client pages I share; deeper integration remains in development.
The product
What it makes possible.
Four parts follow: The Record, Brain, Jarvis OS and the earlier experiments. The screens are local runs of each product’s own code with invented projects and people; two are existing captures, marked as such.
01
The Record · manage the work
Project management for developers, clients and connected coding agents. Agents update pages through revision-checked commands with exact-retry receipts, over connections that expire after seven days and can be revoked.
02
Brain · preserve the context
Durable engineering memory for project state, findings, repository maps, workflows and handoffs, navigable as a graph of more than a thousand linked pages.
03
Jarvis OS · coordinate execution
A supervisor that has handed bounded tasks to visible Claude Code and Codex workers in recorded trials and reports each one’s real final state. Silence is never treated as success, and an offline worker makes the whole loop testable without paid runs.
04
Where it came from
Three earlier experiments, a repository that acted as an assistant, a planner and executor split, and a session cockpit, decided which ideas were kept.
05
The working cycle
Plan a bounded milestone, pursue that work, capture questions and evidence, then review the outcome before planning the next scope. Engineering judgment and release accountability stay with the developer.
At a glance / simplified product view
01The Record
02Brain
03Jarvis OS
The Record · manage the work
One page per project that people and agents both keep current.
The Record holds what a project is, what is built, what is checked and what is needed next, on a page a client can read. Its owner edits it, a reader answers questions where they arise, and an approved AI agent updates it through commands that cannot be applied twice.
The workspace homePersonal projects, development pages and client folders across one page, with work shared by others on the right. Local run of the product’s own code with invented projects and people.One page, two viewsThe same project page for its owner, with the controls to edit and share, and for a reader, with none of them. Local run of the product’s own code with invented projects and people.A question answered where the work isA client question sits inside its milestone: the reader answers there, and the owner sees the saved response in the same place. Local run of the product’s own code with invented projects and people.Progress that can be countedMilestones with a percentage or the words Not measured, headline figures, and step bars that say where each step is waiting. Local run of the product’s own code with invented projects and people.An agent connects, saves, and cannot save twiceA person approves a seven-day connection; the agent’s save comes back with a receipt, and the same command sent again is answered as a replay. Local run of the product’s own code with invented projects and people.
Brain · preserve the context
Engineering memory that the next session can find.
Brain keeps project state, findings, repository maps, workflows and handoff notes as linked pages, with a search tool every session starts from and a viewer for reading them as a graph.
The real graphBrain’s knowledge graph: projects, repositories, knowledge pages and workflows as one navigable map. An existing capture; project names are blurred. Local run of the product’s own code with invented projects and people. The first picture is an existing capture of the real graph with project names blurred.A finding, read beside the graphOne finding open in the reader: what was seen, what was decided, where it is proven and what it led to. Local run of the product’s own code with invented projects and people. The first picture is an existing capture of the real graph with project names blurred.Every project’s backlogOne section per project with active, open, deferred and done columns. Local run of the product’s own code with invented projects and people. The first picture is an existing capture of the real graph with project names blurred.Search from the terminalThe search every session starts with: ranked results as path, title and a snippet. Local run of the product’s own code with invented projects and people. The first picture is an existing capture of the real graph with project names blurred.A handoff noteWhat carries work to the next session: where to resume, who can unblock it, what is finished, half done and only looks finished, and the exact next action. Local run of the product’s own code with invented projects and people. The first picture is an existing capture of the real graph with project names blurred.
Jarvis OS · coordinate execution
A supervisor that reports each worker’s real final state.
Prototype · bounded trials, the full conversational cycle is still proposed
Jarvis OS writes a goal down as steps with a test for each, hands one step to a worker inside a fence, and says plainly when a step is blocked. An offline test worker makes the whole loop checkable without a paid run; real workers were used in recorded trials.
A goal becomes steps with a testA goal written down as three steps, each with a done-when test; the step with nothing to prove it is refused one. Local run of the product’s own code with invented projects and people. The worker in the terminal pictures is the offline test worker; the last picture is an existing capture of a real worker from an August 2026 trial.One step, handed over in writingA step given to a worker, and the assignment as written: what to do, how it will be judged, where it may write and the one command it may run. Local run of the product’s own code with invented projects and people. The worker in the terminal pictures is the offline test worker; the last picture is an existing capture of a real worker from an August 2026 trial.The fence, tried by handA write inside the worker’s folder is allowed; a write elsewhere, an edit to standing instructions and any other command are blocked. Local run of the product’s own code with invented projects and people. The worker in the terminal pictures is the offline test worker; the last picture is an existing capture of a real worker from an August 2026 trial.The unattended loop, and its refusalThe loop working through plans with the test worker, the account it leaves, and its refusal to drive a real worker unattended until the fence is proved on one. Local run of the product’s own code with invented projects and people. The worker in the terminal pictures is the offline test worker; the last picture is an existing capture of a real worker from an August 2026 trial.A real worker, August 2026A real Claude Code worker started by the supervising prototype with one bounded task, doing it step by step in its own window. An existing capture; a name and an account line are covered. Local run of the product’s own code with invented projects and people. The worker in the terminal pictures is the offline test worker; the last picture is an existing capture of a real worker from an August 2026 trial.
Earlier experiments
The ideas that were kept.
A repository that acted as an assistant came first: hooks that loaded saved state at the start of a session and held work at a planning gate. Its memory and enforcement ideas fed Brain; its delegation ideas became Jarvis OS.
The first assistant’s retrieval receiptWhat the earliest version put in front of the assistant when a session opened: what was loaded, the active thread, key facts and the projects table. Local run of the product’s own code with invented projects and people. The hooks are the earlier product’s own scripts run over invented state.The moving parts, as designedThe product’s own explainer: the user, one front door, a project manager per live goal and the builders each one runs. Local run of the product’s own code with invented projects and people. The hooks are the earlier product’s own scripts run over invented state.
Engineering choices
The decisions behind the interface.
01
Give each product a clear responsibility.
The Record holds project scope and evidence, Brain retains engineering context, and Jarvis OS explores supervised agent execution. Keeping those responsibilities explicit makes unfinished integration visible.
02
Refuse to guess.
Unknown is a first-class outcome: a worker that cannot prove it finished is reported as unknown, and a retried update has exactly one effect.
The Record and Brain support my development workflow and client pages. Deeper integration with Jarvis OS is the next step.
Where it stands
In daily use, with more to connect.
Bring project context and engineering memory into a more unified assistant experience. The complete proposed integration is not presented as a finished autonomous platform.
