I Tried the Tools. I Ended Up With a Few Plain Text Files.

Let me start with the conclusion: on the question of getting AI agents to actually do useful work, I tried two tools recently and failed to figure out either one.

One is superset.sh — a local-first desktop workspace that runs several coding agents at once, each in its own isolated git worktree on its own branch, with a single panel where you review all the diffs before deciding what to merge.

The other is multica.ai — open source, built on the idea of managing coding agents like teammates: a task queue, statuses, comments, an activity timeline, and a reusable "skills" library, with a local daemon dispatching whichever agents you have installed.

Both are serious pieces of work, and neither is trying to replace Claude Code or Codex. They sit above those tools. They're the management layer.

I installed them, opened them, looked around for a while, and closed them.

It took me a while to work out why. It isn't that I'm lazy. It's that what they sell, I'd already built by hand.

"One isolated worktree per agent" — my own global rules have required that for a long time: when several sessions run in parallel, each session gets its own worktree, with explicit criteria for when to open one, when not to bother, and how to reclaim it afterwards. That rule wasn't reasoned out in advance. It was beaten into me by sharing a single tree: someone else's uncommitted files showing up in my git status, commits that had to list every path by hand, and release time arriving without anyone knowing which commit to pin.

"A reusable skills library" — that's my pile of skill files, the per-repo project instructions, and a dozen or so interception rules. That is the library.

So the abstraction these tools hand you doesn't line up with the one that had already grown on my machine. They want me to move mine into their model, and mine was hammered out one pothole at a time, each rule backed by a specific instance of real waste.

Meanwhile, the three things that actually saved me time this week used no tooling at all.

I. An instruction file in the wrong place may as well not exist

I have a dozen-odd repos, each with a set of project notes written for the AI. Until this week, each kept a copy in both CLAUDE.md and AGENTS.md.

I spent half a day this week collapsing every repo into one shape: the real content lives in AGENTS.md, and CLAUDE.md is five lines pointing at it.

The reason is three mechanics I verified on my own machine, each with a control:

• Claude Code reads only CLAUDE.md.
• Codex reads only AGENTS.md.
• Neither one reads the other's file.
• Claude Code expands @ imports. Codex does not.

So "put the content in CLAUDE.md" leaves Codex completely blind, and "keep a copy in both" guarantees drift. That second part isn't a prediction — it's what I found. Three repos had an AGENTS.md still teaching a deployment method retired long ago. And one repo's two files contradicted each other on how production database migrations run: one said to use push mode, the other said "do not restore push mode."

I went to the code to settle it. The one saying push mode was both stale and dangerous — it described exactly the practice my own hard constraints forbid.

A document nobody reads is just waste. Two documents that contradict each other can hurt someone.

II. Rules written as prose die. Gates don't.

My project notes have long carried a rule: scale verification to the blast radius; don't mechanically run the heaviest command in the repo.

Then, in one session this week, twenty-five of forty-four minutes produced no information whatsoever:

• I'd changed two files, and went and ran all 742 test files in the repo. Forty-one minutes later it still hadn't finished and got killed. The two directories that actually mattered ran 210 cases in 33 seconds, all green.
• I started a background command and then wrote a polling loop to watch it, hitting the tool timeout twice in a row — when a finished background task announces itself anyway.

The rule was right there in black and white. It died anyway. Prose rules do that.

So instead of bolding the rule one more time, I turned those twenty-five minutes into a hook: it blocks the action outright, and tells the agent what to do instead. If you genuinely need the full run, one comment lets it through.

That fixed a subtler failure along the way. When an interception fired, it had only been sending back a single line — "denied" — so the carefully written "here's what you should do instead" in the rule file never arrived. The same session burned three more cycles in the same hole for that reason.

Blocking the wrong action is only half the job. Handing over the right one is the other half.

III. "A bit slow" is not an adjective. It's a number you have to measure.

Users reported three slow pages. I diagnosed the first round from memory and intuition, and got all of them wrong.

So I did it properly: took a copy of the production database and wrote a script that times each capability and reports four numbers — total time, how much of it is SQL, how much is CPU, and whether the second call is any faster.

Once the numbers landed, it was no longer a mystery:

• The exceptions page: 649ms, of which SQL is 0ms. All CPU. The root cause was a graph with 9,277 nodes and 26,567 edges, where every per-object link lookup was a full linear scan — 3,188 objects scanning it twice each. Building the index up front when the graph is constructed took 649ms to 6ms.
• The company vitals board: 722ms to 6ms. But the number isn't the valuable part. What I found along the way is: that page polls every 10 seconds, and every poll was flushing the read cache for the entire organisation. Meaning one person leaving that page open put everyone else's pages back into a cold start.
• The other two pages I measured, I decided not to touch. One is 1ms warm — the "one to three hundred milliseconds" I remembered was the cold-start figure. The other spends 38 of its 41ms on an aggregate that has to scan 165,000 rows by definition; no index fixes that, and it isn't worth inventing a materialised table for.

Three pages: two changed, one explicitly left alone, all three backed by numbers.

And one step you can't skip. After the change, I ran all 3,188 objects through both the old and new paths and compared answers, confirming zero discrepancies. Because if you get the index direction backwards on a change like this, the page just shows different numbers. Nothing throws.

Coda

Looking back, the three things that saved me time this week were: moving a few markdown files, writing a few dozen lines of interception script, and writing a timing script.

Not one of them required installing anything.

I don't think superset or multica are worthless. Quite the opposite — the problems they're aimed at are real ones. Running several agents in parallel, dispatching work, compounding experience: I do all three every day. It's just that I've noticed something. Before the potholes have beaten your own method out of you, a management-layer tool is managing something you don't have yet. And once they have, you need it rather less.

How wide that window is, I don't know. Maybe I just missed it.

What I've been short of was never a better dashboard. It was writing my own crude methods down — and making them actually bite.

Break through the heavens; face fate head-on.