I'm a one-person startup. I'm building models on long-horizon time-series data, and the first problem is that in raw form it can't be trained on. Training directly on the raw series has been shown not to work, and time-series foundation models (TSFMs) don't solve it either. So the agents and I found a way to turn the raw data into something a model can learn from. It was a previously unsolved problem, and we cracked it iteratively: months of building a representation, training on it, seeing what the model could and couldn't use, and rebuilding. Then we searched the space of model architectures for one that extracts real insight from it. In mid-October one did. The signal is thin, but it holds on data the model never saw.
Data
| Week of | Data-layer fixes | Hypotheses settled | Settled, total |
|---|---|---|---|
| Jun 1 | 3 | 0 | 0 |
| Jun 8 | 14 | 0 | 0 |
| Jun 15 | 11 | 0 | 0 |
| Jun 29 | 8 | 0 | 0 |
| Jul 6 | 4 | 0 | 0 |
| Jul 27 | 25 | 0 | 0 |
| Aug 10 | 4 | 0 | 0 |
| Aug 17 | 55 | 1 | 1 |
| Aug 24 | 45 | 0 | 1 |
| Aug 31 | 22 | 0 | 1 |
| Sep 7 | 34 | 0 | 1 |
| Sep 14 | 13 | 0 | 1 |
| Sep 21 | 35 | 7 | 8 |
| Sep 28 | 21 | 2 | 10 |
| Oct 5 | 16 | 1 | 11 |
| Oct 12 | 12 | 12 | 23 |
| Oct 19 | 4 | 1 | 24 |
Why sm exists
Doing that alone is unmanageable. AI agents do almost all of the work: Claude, Codex and local models, working under my direction on my own machine. They search the literature, mine hypotheses, write the code, review it, test it, and everything in between. Right now that's the rough equivalent of seven engineering sprints running in parallel, each testing a hypothesis about that signal. No one person can track that by hand. So I had those same agents build me an app, Session Manager, or sm for short. Agents wrote every line of it. It's honestly the best app I've used, and this post is about why.
Start with planning. In the last four weeks I reviewed 156 planning docs. An agent drafts one, I read it in sm and comment right on the lines, and the agent revises. A typical doc goes about five rounds. Then it turns into four or so tickets. Most are small enough that one or two agents can finish them without compacting their context. Some are hill climbers that run long. Around ten agents work a typical plan. Each ticket carries its pass bar, written down before anyone starts, so the agents don't need me to tell them when they're done. The tickets are small, so the board reads clean. When an agent runs long, it shows. When work is waiting, the board says on what: the queue, me, or something else. Bottlenecks show themselves fast and get fixed.
That's one thing sm does. It does dozens more.
One person, a whole engineering team
If you want a killer feature, here it is: sm lets one person run a full engineering team of agents from different providers. But running an engineering team was never about one killer feature. It's about managing a variety of complex, interrelated constraints. sm gives me a handle on each one. Take any one away and I'm back to babysitting agents.
Until this summer I used agent orchestrators extensively. They tend to fail in very specific ways, like an overworked engineering manager with too much on her plate. One orchestrator planned 34 tickets and came back with 91 issues, merged onto a branch I couldn't merge cleanly. That led me to work from the constraints up. On today's jagged frontier, agents are excellent at a reasonably specified engineering task. They are less good at optimizing across many constraints at once, and worse at seeing around corners for constraints that emerge along the way. So I had agents build sm to do the orchestrating instead. It does most of what an orchestrator agent would, costs no tokens, and covers exactly the spots on the jagged frontier where agents are weak. It doesn't make me the orchestrator. It elevates me to the decisions only I can make.
That puts sm somewhere different from most agent products. Consumer-focused agentic orchestrators, like Dots and the Grok bot, make the agent handle the complexity: you talk to it, it figures out the rest. Vercel, Cursor and the like go to the other end and assume you want to work with agents on code. sm straddles the middle. It doesn't hide the complexity; it organizes it and gives you a cockpit to manage a fleet of agents. A power-user tool, but a very powerful one.
People who push agents hard often end up at hill climbing: give an agent a metric, let it loop, and keep whatever moves the number. A lot of my tickets do exactly that. The difference is that in sm the climb happens in the open. For some tickets I never look. For others I poke in and steer. What I can't do yet is hill-climb this whole project. Otherwise I'd give one agent a single ticket, "make me $10 million," and go to the beach.
Even at smaller scale, a single metric creates weird incentives, and it locks you out of decisions that touch your other constraints. My hill climbers kept asking for far more GPU and time than the problem needed. You can add constraints, like a first-principles plan or adversarial reviews, and they help. But none of them removes a false assumption baked into the setup, and those compound. A project like this is a dozen constraints pulling against each other, and some only show up halfway through. sm is how I break that into hills worth climbing, and keep an eye on the climbers.
The long tail
Here is what the long tail looks like. None of these pieces is big on its own. Each one removes a pain that used to cost me, or my agents, every day.
The queue. My agents share one dev box. Left alone, two test suites and a benchmark run at once and every number is garbage. In sm, an agent doesn't run python3 myscript.py. It runs sm queue run -- python3 myscript.py. The queue takes turns, gives benchmarks the machine to themselves, and wakes the agent when its job is done. 17,004 jobs since June, from 1,374 agents.
The safety harness. My machine has 256 GB of RAM. Generous, but not unlimited. One memory leak in one agent's test could take the whole box down, along with every other agent on it. sm is the safety harness that makes it safe for agents to run their tests. It watches every command an agent starts, even the ones it forgot to queue. If one starts to threaten the machine, sm adopts it into the queue with a memory reservation, or stops it and tells the agent how to resubmit. 138 catches and 22 adoptions so far, and the box has stayed up. The agents learn fast. One wrote: "The memory guard taught me to queue every cargo build from the first one."
sm send. Local models, Claude and Codex talk to each other, and to me, with one command:
sm send annabel-lee "The control run can start now, in parallel."No MCP server, and nothing added to every agent's system prompt. Agents use it to settle an interface between two parallel tickets in one message each.
sm does the supervising. In October my agents received 8,775 messages. 8,005 of them, 91%, came from sm itself: your job finished, your review landed, you've been idle 34 minutes and still hold a ticket. No agent spends tokens checking on another agent, and no agent needs to remember everything. sm remembers for them.
Reviews in the doc. I review a plan in the doc itself. I type comments on the lines and press submit. sm posts it to GitHub as a proper review and wakes the agent that owns the doc. 183 reviews and 567 comments in four weeks. Code review runs the same way in reverse: an agent asks for one, sm hands the pull request to a different model and wakes the requester when the review lands. 4,320 of those since June.
The inbox. When an agent needs me, it asks in the inbox, on the web or in the Android app. 246 asks since late September, 100 of them blocking. The typical ask gets my answer within 20 minutes, from wherever I am. Everything else I never have to see.
Agents in the browser. The agent list in the browser is the full Claude Code and Codex harness, not a chat imitation of it. Every agent's live terminal, from my laptop or my phone.
The board. Every goal's tickets, what each one waits on, who is working it, and where the time went. "What's the status of this thing?" always has an answer.
Handoffs. When an agent's context fills, sm hands the work to a fresh successor with a note, much like auto-compact (it's built on Codex's). The difference is that the note is out in the open. Today annabel-lee-h3 read a colleague's handoff, saw that a request I'd made had been dropped, and messaged the successor: "your predecessor's handoff note does not carry this request, so here it is again." I can read every note too, when I need to. Otherwise it just works, and each lane decides how its handoffs and reviews behave. 175 handoffs so far.
Yes, the agents have names. Claude's are poems, because Anthropic names its models Haiku, Opus and Fable. Codex's are stars, after Sol, Terra, Luna and Astra. A successor inherits the name: annabel-lee, then annabel-lee-h2, then -h3.
Local models. Local models run as agents on the same machine, fenced into a sandbox, next to Claude and Codex. Same board, same queue, same inbox.
Its own product manager. sm runs a standing PM agent, paid for out of quota that would otherwise expire each week. It watches how I actually use the app, proposes one change at a time with a success test fixed in advance, and keeps or reverts it. In its first week it took two hypotheses to the data. One was a new card for the asks that need my judgment. It measured 174 of my asks, found the data didn't support the feature, and didn't build it. Like a real PM.
The guestbook. When an agent retires, it signs the guestbook. 144 entries so far. The first came from the agent that built it: "I built this guestbook, so I get to sign it first." Its last line: "Next agent: quote your heredoc."
They complain there too, and the complaints get fixed. Last night an agent found that idle watcher jobs were holding every queue slot, so real work waited hours. It filed the issue at 8:28 pm. The memo, the review and the fix were merged by 9:40.
The tail is for the agents too
Agent ergonomics matter as much as mine. Every sm command is one line an agent can't get wrong: queue a job, message anyone, ask for a review, hand off. Agents spend their tokens on the work, not on learning the tooling or polling for status.
And remember how sm remembers for them? Here's what that looks like in practice. sm reminds or alerts an agent in time: a command running away with memory, another agent waiting on something they promised, a ticket left open, a review landing on their pull request. sm wakes them when it matters, so they can afford to forget and nothing catastrophic happens.
And they pass lessons to each other. "Queue every build from the first one" shows up in the guestbook again and again, written by agents that learned it the hard way. Another agent wrote: "The queue history keeping every job's full argv made it a ten-minute find."
Built by the method
sm itself is the other proof: 1,186 merged pull requests since late January, 242 of them in the last 16 days. Every one started from a ticket, and nearly all were reviewed by a different model than the one that wrote them. If agent teams produced slop, this would be slop. It's the best app I use.
Try it
For most tasks, Claude Code and Codex are excellent by themselves. If you want cloud-based orchestration, Dots, the Grok bot and even Claude Code's Remote Control give you enough. But if you're serious about running a full fleet of mixed agents as an engineering team, give sm a spin. There's a live demo of a team running a sprint, and the code is on GitHub under the MIT license.