Hapimatic Explained

Here is the mental ladder I climbed, and I think most engineering teams are somewhere on it right now.

You start with one AI coding session. You type, it works, you review. If you are good at it, that one session makes you noticeably faster. Call it the first rung.

Then you notice that the session spends most of its time working while you wait, so you open a second one on a different task. Then a third. A disciplined engineer can keep three or four going. This is where most power users are today, and it feels like a superpower. Call it rung two.

Now do the arithmetic the way a manager would. If one engineer with one session is more productive, and one engineer with four sessions is more productive still, then four engineers each running four sessions is great. What if each of your four engineers were running forty?

That is not a hypothetical. As I write this, my Hapimatic session list holds more than a hundred and fifty sessions. Not all of them are active at once, but they are all there: parked, resumable, each one a container for a piece of work that I or an agent can reactivate. The question is no longer "can the AI do the work?" It is "who is managing a hundred concurrent streams of work?" Because a person cannot. You physically cannot hop between a hundred terminals, remember where each one is, notice which one has stalled, and answer the three that need a decision, all while doing your actual job.

The vendors have noticed the problem too. Sessions can now message each other in the mainstream harnesses, which is genuinely useful. But look at what that does and does not solve. Two sessions talking to each other is still two sessions, and you are still the one deciding who talks to whom, about what, and when. The coordination has not gone anywhere. It is still in your head.

The leverage of AI in engineering is not that it types faster than you. It is that your attention, the scarce resource, can be spread across far more parallel work than you could attend to directly. That only happens if something above the sessions is doing the attending. That something is the meta-harness, and the agent that drives it is the Project Manager.

So here is the one-line pitch, and the rest of the piece is the argument for it: if AI is supposed to raise your engineering output many times over, you need a layer that manages that growth, or the growth stops at the number of plates one person can spin.

Now the layers. I will go from the top, where you interact with the system, to the bottom, where it touches the bench, because that is the order in which the value becomes visible.

Underneath the behavioral system is the open-source Hapimatic core: the session layer that makes everything above it possible. Its job is to provide enough lanes, and to make sure a lane never disappears while work is in it.

• Sessions that never die. Server restarts, harness upgrades, crashes, reboots, API outages, and rate limits do not end a session. Park work for weeks, come back on a different account, and pick up where you left off.
• A fleet, not a box. Every session is a peer of every other: see it, message it, spawn it, on any machine you own or any VM you run. Cluster as many machines as you want and the sessions on all of them appear in one list.
• One app on every device. The same interface on your phone, tablet, and desktop, with every tool call visible and a push notification when an agent needs a yes.
• Parallel work without collisions. A worktree per session, so several agents work the same repository on the same machine at the same time.
• Scheduling. Recurring prompts inside a session, and scheduled events that start sessions on their own, with the controls a real scheduler needs.
• Every transcript, searchable forever. The complete record of every session stays on your node, recoverable by you or by any agent.

None of these is exotic on its own, and several other tools do some of them. The point is that the layers above need all of them at once. You cannot run a Project Manager over sessions that evaporate, or coordinate a fleet that only exists on one laptop, or let a hundred sessions share a codebase without worktrees. The session layer is the floor the rest of the building stands on.

4.6 The engine: your harness, your subscription

At the bottom is the model, reached through the harness you already use. Hapimatic does not sell tokens and does not sit between you and the model provider; each session runs the harness as your own process, signed in to your own account through the provider's own flow. Harnesses supported at launch are Claude Code, Codex, Gemini CLI, and OpenCode; the status of each is on the install page.

This is also why the model is swappable. The behavioral system is written in natural language against a harness, not against a model. When a better engine ships, it drops into the same car.

Under Hapimatic, the engineer's job changes shape. You are at the front end, saying what you want: a feature, a fix, a bring-up, a review. You say it in plain language, by voice if you like, and the system turns it into issues, and issues into epics. Then you are at the back end, verifying what came out. I do not take the system's word for it. If it tells me the firmware works now, I want to see the measurement before anything ships to a client.

Everything between those two ends is where the system runs without you in the critical path. This is what people mean by "human on the loop" rather than "in the loop." You are not approving every step; you are stating intent and confirming results, and the layer below is responsible for everything in between.

4.2 The Project Manager: the layer that makes scale manageable

The Project Manager is an ordinary session that has been given a role. The role is a skill, a few hundred lines of instructions for how to run a fleet, and the capabilities it needs are the same ones every session has: it can list other sessions, spawn new ones, send them messages, read their state, and shut them down. Give those capabilities a role and a manager falls out.

A run looks like this. You hand the PM an epic (or a milestone, a board, or just a list of issues) and walk away. It reads the plan, works out which issues depend on which, and which are safe to run in parallel. It spawns one peer session per issue, each in its own worktree, on whatever machine in your fleet has room. Each session takes its issue through the same workflow: formatted, researched, implemented, tested, closed. The PM checks on them on a schedule: what moved, what stalled, what needs a decision. It unblocks what it can. When something needs your judgment (a research plan that is not confident enough, a risk threshold, a question only you can answer), it brings you that one decision, in its own session, with the context to answer in one reply, and pings your phone so you know.

Two things about the PM are easy to miss.

First, it stands on the shoulders of everything below it. I could not have written a project-manager skill for a bare coding harness. The PM needs a substrate: sessions that survive, an API to spawn and steer them, worktrees that keep them from colliding, a database of what each session is working on, and a durable record to read their progress from. The PM is the keystone, but it is the keystone of an arch that had to exist first.

Second, it is the thing that moves you from rung two to rung four. Without it, you are the one orchestrating. You are back to four sessions and a lot of tab-switching. With it, the number of sessions is bounded by machines, not by your attention.

The high-water mark, measured rather than estimated: the Project Manager that is running Hapimatic's own productization program started on October 3, 2026 and was still running as this was written on October 29, 2026. In those 26 days it accumulated 164 hours of agent time across 8,727 messages in its own session, spawned 72 peer sessions directly, and drove its program board to 389 of 520 items done, while the repository merged 559 pull requests and shipped 474 releases. Every one of those figures is read from the system with a command that anyone with access can rerun, and they will keep moving until the board is complete.

A manager is only as good as its procedures. The behavioral system is the accumulated set of skills and hooks that turn "do the right thing" into something repeatable. I have been building it since early 2025, and it has three parts.

Skills, in a hierarchy. At the bottom are primitives: format an issue, research it, write the plan, implement it, test it, review the pull request, merge, close. Above those are composites: run the whole issue workflow, triage a backlog for parallel-safe work, sweep a repository and format every new issue. At the top is the PM, which calls whatever primitives the job needs. There are around ninety of them at the moment, and each one has been rewritten more times than I can count, because every time one of them failed in a new way, it got better.

Hooks, as guardrails. Around a hundred and fifty of them. Each exists because the model once did something I did not want: pushed to the wrong branch, claimed a test passed without running it, skipped a verification step, declared a board safe to power without reading the schematic. Each of those became a mechanical block. That last one is worth dwelling on: the agent once called a bench setup safe without checking the drawing, so now a rule blocks any power-up advice that does not cite the schematic trace. The rule came from its own mistake.

The workflow state machine. Every issue moves through fixed stages, and each stage applies a permanent checkpoint label on the issue itself: formatted, researched, implemented, tested, closed. The labels only move forward. A lock label prevents two sessions from working the same issue at once. The research stage rates its own confidence and, below a threshold, runs more research or kicks the issue back to a person. Low-risk, well-understood issues flow through without approval; anything risky, complex, or uncertain pauses at a gate you chose.

The workflow defines structure, not content. A word processor does not tell you what to write; it gives you a page, paragraphs, headings, and a way to track changes. The issue workflow is the same. It does not care whether the issue is a firmware bug, a website change, or a schematic review. It cares that the work moves through the same stages, leaves the same evidence, and lands in the same place.

Trust comes from the combination. You cannot prove mathematically that a given set of skills and hooks can never go out of bounds. What you can do is run the system thousands of times, catch every excursion, and turn each one into a hook or a better skill. Confidence is earned by use, and it compounds. More on that in section 6.

This is the layer that most changes how you think about AI work, and it is almost invisible once you are used to it.

In a chatbot, the work lives in the conversation. Close the tab, lose the context, hit a rate limit, or let the model's own context window fill and compact, and some of that work is gone. In Hapimatic, the work lives on the GitHub issue. The original request, the structured version of it, the research and the implementation plan, the commits, the test results and screenshots, the review, and the closing summary are all attached to the issue as it moves. The session is disposable. The issue is not.

Three consequences.

It is a safety net. A session can crash, a machine can reboot, an API can go down, and nothing is lost. The next session reads the issue, sees exactly which stage it reached, and continues.

It is connective tissue. Session one and session two are working the same repository. They do not need to talk to each other directly. They read and write the same issues, the same labels, the same branches. The work surface is how a hundred sessions coordinate without a hundred conversations.

It is an audit trail. Six months from now, "when did we change that behavior, and why?" is a search. Find the issue; the full record is there. Anyone with access to the repository, including a client, can see what is being worked and in what state, without asking.

If you already work in Git, you already have the substrate. The Issue Workflow seeds into an existing repository with its existing issues; there is no migration.

Everything above applies to any software work. This section is why Hapimatic exists in a hardware consultancy, and it is the capability I have not seen anywhere else.

The hardest part of applying AI to hardware is that the result of the work is physical. The firmware either makes the LED blink or it does not. The regulator either holds the rail or it does not. If the agent cannot see the LED and cannot measure the rail, then a person has to look, read the number, and type it back into the chat, and the person is the bottleneck again. Worse, the agent is reasoning from the schematic alone, telling you what should be happening rather than what is.

So the test-and-iterate stage of the workflow extends onto the bench. A camera over the workbench lets an agent look before it concludes: is the board powered, did the display update, is the LED flashing? Instruments in reach let it measure: capture the rail at power-up on the oscilloscope, profile the sleep current, load the output. A debug probe lets it flash the board. The loop is observe, measure, reason, change, measure again, and keep going around until the readings say the bug is gone. The rule I hold the system to: a bug is not fixed until it is explained and proven by a measurement, and the before-and-after captures are attached to the issue for you to check.

Two cases from the talk I gave at Drexel this month, both anonymized.

A cellular wearable sensor arrived abandoned, with a battery gauge that said it would last about a day. The agent drove the power profiler itself: flash one firmware level, unplug the debugger, measure, repeat. Every level sat on the same sleep floor. The gauge was wrong; it had never been told the battery's size, and one default assumed a sleep current a hundred times the real one. The measured average worked out to about nine days of runtime, not one. It went from not working to working in the field.

A battery-powered audio device drew 138 milliamps while it was supposed to be asleep. The agent wrote the deep-sleep firmware and the state machine on a new microcontroller; I measured on the profiler. The result was 1.2 milliamps asleep.

Teaching it a new instrument

Here is the part that makes this a framework rather than a trick. Anyone can sit down and teach a coding assistant to drive one logic analyzer. The question is what happens when you also want the oscilloscope, the electronic load, the power profiler, and the camera, and you want them to work in concert, and you want the system to remember that it knows how, so that next time you do not have to say "use the oscilloscope skill."

Hapimatic has a procedure for learning an instrument. Give it the model number, or the manual, or the vendor's page. It finds the drivers, or writes them. It works out the communication protocol. It talks to the instrument, tests that it can control it, validates every method against the real hardware, and then catalogs the instrument as a capability it has. The analogy I use, at the risk of sounding unprofessional, is the scene in The Matrix where they plug the cable into the back of Neo's head and a moment later he says, "I know kung fu." Say "learn this oscilloscope," and a while later the system is an expert in it, permanently.

From then on, the tool selection is automatic. When an issue points at a power problem, the system knows the power profiler is the right instrument, knows it knows how to use it, and asks you to set it up. That is the difference between a one-off integration and a framework: the capability is cataloged, composable, and reached for from context.

Safety, briefly

The functionality is what engineers ask about. The safety is what the people who approve budgets ask about, and rightly: how do I know this thing will not blow up my lab? The short answer is that looking is free and changing the physical world is gated. The agent can read a camera or a meter whenever it likes. Switching on a supply, changing wiring, or energizing a board waits for a person, and a power-up recommendation that does not cite the schematic is blocked by a hook before it reaches you. The gates are in the path, not in the prompt.

One more property, and it is the one I would point to if someone asked what makes this system different in kind rather than in degree.

The methodology improves through use, mechanically. Regulated industries call the pattern CAPA, corrective and preventive action, and it is the same shape here.

1. A mistake happens, and a hook is added. The model does something wrong. The incident is logged, and a hook is written that blocks that specific action. That is the corrective action.
2. The hook keeps firing, so the cause is fixed upstream. If the same hook catches the same thing across many sessions, the problem is structural: a skill is ambiguous, two instructions contradict, a template produces the wrong frame. The root cause is fixed. That is the preventive action, and it is the more important of the two.
3. The hook stops firing, and it retires. Once the upstream fix holds, the hook's firing rate drops to zero and it is deleted. The system has hardened against a class of failure, permanently, and the attention that used to go to that class is free for the next, more abstract one.

The behavioral system is itself a Git repository, and it is processed by its own workflow. When a skill needs refinement, I file an issue against it, and the same formatted-researched-implemented-tested-closed pipeline that processes client work processes the methodology. The system uses itself to improve itself. When it trips over an edge case, it files the bug.

It trips often. As of October 11, 2026, the project's own repository had 1,012 issues labeled as bugs, 735 of them closed. I say that as a point of pride, not an admission: every one of those is a failure mode that was caught, recorded, and turned into a fix, in the record, where you can read it. A system that never files a bug against itself is not a system that never fails. It is a system that does not notice.