DEV Community: Somesh Bhardwaj

Six agents were running and I could not tell you what any of them did

Somesh Bhardwaj — Sat, 05 Sep 2026 06:50:08 +0000

Six coding agents were running. I could not tell you what any of them had
done.

Not roughly. Not approximately. The output was there, the files had changed,
and the honest answer to "which one did that" was a shrug. Three questions in
particular had no answer: which run burned the tokens, whether they genuinely
ran at the same time or merely started together, and whether two of them had
quietly edited the same file.

That last one is the expensive question. An agent working on the wrong file
looks exactly like an agent working on the right one, right up until you read
the diff.

The thing that was already true

Every one of those runners writes a transcript to disk while it works. Claude
Code does. So do Cursor, Codex, Gemini CLI, Copilot CLI and Kiro. The record
of what happened was sitting in my home directory the entire time, in six
different formats, none of which I had ever looked at.

So runlanes does not wrap anything. There is no SDK, no instrumentation step,
no account, and nothing to start before the run starts. It reads what the
runner already wrote.

The consequence is the part I did not expect to matter as much as it does:
it works on runs that already finished. Most tools in this space need you
to have decided, in advance, that this particular run was worth watching. This
one can answer a question you only thought to ask afterwards.

npx runlanes

That opens a console on 127.0.0.1:4180 for whatever project you are standing
in. There is no configuration file to write first.

What it actually shows

Now is every live session, across every runner it found, with what the
main conversation spent against what it handed to subagents. On the session
that motivated the whole thing, that split was 8.3 million tokens of
conversation against 2.1 million delegated, which was not the ratio I would
have guessed.

The parallelism figure is the one I keep coming back to. Peak concurrency was
four agents. The share of elapsed time where anything genuinely overlapped was
9%. Four agents were running, and for 91% of the wall clock they were
politely taking turns. Nobody reports that number, and it changes how you plan
a fan-out.

Graph links runs to the files that more than one of them touched.

The distinction that makes this worth having: an edge exists because a run
opened that file. Not because a prompt said it would. Those are different
claims, and only one of them is evidence.

History is every session found for the project, with spend and agent time.
Docs is the plans, skills and agent instructions sitting beside the
project, which turn out to be the thing you most want to read when a run has
gone sideways.

Refusing to make numbers up

Kiro bills in credits, not tokens. Its transcripts record which files were
touched and which documents were read, and no usage at all.

The console shows a dash.

It would be trivially easy to show 0 there. It would also be a lie of the
most ordinary kind, the sort that makes a dashboard feel authoritative and
quietly poisons every total on the page. An unmeasured run is not a free run.
It is left out of the sums rather than counted as nothing.

The same instinct runs through the token arithmetic. Tokens counted are input
plus output plus cache creation. Cache reads are deliberately excluded,
because they re-report the entire prompt on every single turn, and summing
them across a session counts the same context dozens of times and produces a
number several times larger than anything that happened. They are still
included in cost, because they are still billed. Those are two different
questions and the tool answers them separately.

The claims are tests, not sentences

runlanes reads local files, makes no outbound network calls, and binds to
127.0.0.1. Every tool in this category says something like that in its README.

The difference here is that CI fails the build if any of it stops being
true. There is a step that greps the source for fetch, axios and
https.request and fails if it finds one. A step that asserts 127.0.0.1
still appears in the server. A step that fails if a runtime dependency ever
appears, which is how the dependency count stays at zero rather than
aspirationally low. And one that fails if a vendor name leaks outside the
adapter directory, which is what keeps six runners from turning into six
special cases scattered through the app.

A README claim is a sentence somebody wrote once. A CI step is a claim that
has to survive every commit. I would rather ship the second kind.

Where the package came from

Published from GitHub Actions through OIDC trusted publishing, so npm records
the commit, the workflow and the runner that built the tarball. npm audit signatures reports a verified attestation, and anyone can check that what is
on npm matches what is on GitHub. Sigstore signs it with a certificate that
lives about ten minutes and files the record in a public transparency log, so
there is no long-lived signing key to steal.

For a tool whose entire argument is "these numbers survive checking", it
seemed inconsistent to ask anyone to take the tarball on faith.

The demo is the product

runlanes --export writes the whole console to a single self-contained HTML
file. The live demo is that export,
rebuilt by CI whenever the source changes. It is not a screenshot and not a
mock, which means a change that breaks the console breaks the demo in CI
before it reaches anybody.

The demo also says in its first line that its runs are staged. A tool arguing
that its numbers can be checked should not open with invented data presented
as real.

It was called something else

This shipped as "agenttrace" for about a fortnight. Then I looked properly,
and five published CLIs already install a binary by that name, one of them
with a near-copy of my own opening line in its README.

The registry entry was still free. Taking it would have meant winning the
package name while losing the command name, the search result and the
repository name, which is losing three arguments to win one.

"runlanes" is also just a better description. The timeline draws one lane per
run, and whether those lanes overlap is the entire question.

Try it

npx runlanes

MIT, Node 18 and up, zero runtime dependencies, 95 tests running on Node 18,
20 and 22. The source is on GitHub
and the package is on npm.

If you run more than one agent at a time, the data is already on your disk.
This just reads it.

Routing email into Slack, which is not the same as forwarding it

Somesh Bhardwaj — Sat, 05 Sep 2026 06:50:05 +0000

Every organisation that works in Slack still has email arriving somewhere
else. Vendor notifications, form submissions, the address a partner replies
to. The work is in one place and a meaningful slice of the information about
it is in another, which someone checks when they remember.

The obvious fix is forwarding. Point the mailbox at a Slack channel and let
the integration post everything. It takes an afternoon, and it fails in a way
that is worth describing precisely, because the failure is not "it did not
work". It is that it worked exactly as specified and made things worse.

What forwarding actually produces

Truncated bodies. The integration posts a preview. The part of the email
that says what to do is below the fold, so every message becomes a link to the
thing you actually needed, and the channel is a table of contents for an inbox
people are still opening.

Reply chains, repeatedly. A thread with six replies does not arrive as one
conversation. It arrives as six posts, each quoting all the previous ones, so
the channel fills with the same text at increasing lengths.

Auto-replies. Out-of-office, delivery receipts, no-reply confirmations.
None of it is work and all of it arrives with the same weight as the message
from a partner asking a real question.

The predictable outcome is that the channel gets muted, and now the
information is in two places neither of which anyone is reading.

Routing, not forwarding

The distinction that makes this work: a router decides what belongs in Slack
and in what shape, rather than moving everything and hoping the reader
filters. Concretely that means four things the forwarding integration does
not do.

Deduplication on the RFC Message-ID. Every email carries a globally unique
Message-ID header, and replies carry In-Reply-To and References pointing
back at what they answer. That is the correct identity for a message, rather
than a hash of subject and sender, which collides on exactly the automated
mail you receive most. The router keeps a seven-day lookback of what it has
already posted, which is long enough to cover a thread going quiet over a
weekend and short enough that the state stays small.

Thread and reply detection. Because the headers say what answers what, a
reply can be posted into the Slack thread of the message it answers instead of
starting a new one. The conversation in Slack has the shape of the
conversation in the mailbox, which is the whole point and is the thing
forwarding cannot do.

Body extraction rather than preview. Multipart MIME, quoted history,
signature blocks and tracking pixels are all separable from the sentence
somebody actually wrote. Extracting that means the Slack message is the
message, and nobody has to open the mail client to find out what was being
asked.

Noise suppression. Auto-replies and no-reply senders are identifiable
before posting, not after. They are dropped rather than muted, because a muted
channel is a solved problem that will unsolve itself the moment the mute is
lifted.

The detail that decides whether people trust it

The router processes in controlled batches and preserves unread state.

That sounds like an implementation footnote and it is the reason the system is
used. If reading the mailbox programmatically marks messages read, the router
has silently taken over as the only reader, and the person who owns that
inbox has lost the ability to work it directly. They will not say this
explicitly. They will just stop relying on it, because something is now
touching their mail in a way they did not ask for and cannot see.

An automation that changes state it was not asked to change is not a
convenience. Leaving the mailbox exactly as it found it is what makes the
router additive rather than a takeover, and it is the difference between a
tool people keep and a tool people quietly route around.

Where it sits now

Operational email is owned in Slack, where the team already works, rather than
in a side inbox somebody checks. Threads look like threads. Auto-replies do
not arrive. The mailbox still works normally for anyone who wants to open it.

The general principle, which applies well beyond email: moving information
between systems is easy, and almost never the problem. The problem is that the
receiving system has a shape, and information that arrives in the wrong shape
is worse than information that did not arrive, because it costs attention
before it can be ignored.

The message that mentioned finance and tagged nobody

Somesh Bhardwaj — Sat, 05 Sep 2026 06:50:03 +0000

Somebody types "can we loop in finance on this?" in a product channel. Nobody
tags the finance channel. The thread moves on. Three weeks later there is a
contract nobody in finance has seen.

That is not a tooling problem in any obvious sense. Slack worked exactly as
designed. Search would have found the message if anyone had known to look for
it. The failure is that the people who needed to know were never told, and
nothing in the workspace was watching for the difference between mentioning a
team and involving one.

Why keyword matching does not solve this

The instinct is to grep for the word "finance" and alert on it. That produces
a channel nobody reads inside a week, because "finance" appears in sentences
that have nothing to do with governance, and the sentences that do matter
often do not contain the word at all.

What actually carries the signal is structure. A Slack message is not plain
text on the wire. When someone references a channel, it arrives looking like
this:

Can we loop in <#C01ABCDEF|finance> before this goes out?

That is a channel reference, distinct from a mention that notifies the
channel, and it survives in the event payload whether or not anyone was
actually alerted. It means the workspace already knows the difference between
"I said the word finance" and "I pointed at the finance channel and did not
bring anyone in". Nobody was reading it.

So the bot parses references rather than words. It maps channel IDs to what
those channels are for, and it looks for the specific shape of a message that
points at a governance channel from outside it. Context beats keywords, and
in this case the context was already structured and already being thrown away.

Two decisions that mattered more than the detection

It joins every public channel by itself. The obvious build asks an admin
to add the bot wherever it should watch, which means coverage is a function of
somebody remembering. Every channel created after launch is a gap, and nobody
finds out until something is missed in one. Instead it lists the public
channels through the API and joins them, then listens for channel_created
and joins new ones as they appear. Coverage is complete by construction rather
than by diligence, across more than a hundred channels.

It runs on Socket Mode. The usual Slack integration takes an inbound
webhook, which means a public HTTPS endpoint that anyone can reach and that
has to be secured, monitored and kept alive. Socket Mode reverses the
direction: the bot opens an outbound connection and Slack pushes events down
it. For an organisation that would otherwise be exposing a new inbound surface
to catch its own internal messages, that trade is worth taking on its own.

The constraint that shaped the deployment

Socket Mode has a consequence that only shows up on deploy. Because the bot
never receives inbound HTTP, it never binds a port, and the platform hosting
it was watching for exactly that to decide whether the service was alive. A
correctly working bot looked, to the host, like a process that had failed to
start.

The fix is a sidecar: a minimal HTTP server inside the same process whose only
job is to answer a health check.

import express from "express";

const app = express();
app.get("/", (_req, res) => res.send("Bot is running"));
app.listen(process.env.PORT || 3000);

Ten lines that do nothing for the product and without which the product does
not stay running. It is worth saying plainly, because this is the part that
never appears in an architecture diagram and is most of what deployment
actually is: the platform has an opinion about what a healthy service looks
like, and you either meet it or you do not run.

Scopes, deliberately narrow

The bot holds channels:join, channels:history and chat:write. Public
channels only, no user impersonation, no private conversations, no ability to
act as anyone. A tool that reads a workspace to improve governance has to be
governable itself, and the smallest scope set that does the job is the one
that survives the security review it will eventually get.

What it changed

Coverage went from whichever channels someone remembered to whichever channels
exist. Finance mentions that previously depended on a person noticing now
arrive in one place with the surrounding context attached. The work of
watching moved off people and into something that does not get busy or go on
leave.

The wider lesson is about where automation should sit. This one requires no
configuration, adapts to new channels on its own, and nobody in the workspace
has to change how they write. The best version of a system like this is one
the team never thinks about, which is also the version that is hardest to
justify building, because the evidence of it working is the absence of an
expensive surprise.

A small event tool, and the day it stopped being small

Somesh Bhardwaj — Fri, 13 Mar 2026 12:00:33 +0000

The task was scoped as a small automation: North America only, one kind of
event, some registrations and a confirmation email. The kind of thing a
spreadsheet and a script would cover.

It was not that, and the tell came early. The events were multi-session, the
attendees were educators across several timezones, and completion had to
produce a certification that somebody would later rely on. Each of those is
survivable alone. Together they mean state: who registered for which session,
who actually attended, what that leaves outstanding, and what has to happen
next and when. A spreadsheet holds state right up until two things change at
once.

Where the complexity actually lives

Almost none of it is in the event model. Events, sessions and registrations
are a straightforward schema, and if that were the whole job the original
estimate would have been right.

The complexity is that nearly every meaningful fact arrives from a system you
do not control. Attendance lives in the video platform. Whether a reminder was
delivered lives in the email platform. Segmentation lives in the marketing
tool. Whether the event is on somebody's calendar depends on an ICS file being
parsed correctly by a client you have never tested.

Each of those has its own model of a person, its own idea of time, and its own
failure modes. The platform's real work is translation: keeping one coherent
account of what happened while four external systems each report a partial and
occasionally contradictory version of it.

That is why the architecture ends up with an explicit translation boundary
rather than external calls scattered through the features. When the video
platform changes what it returns, the change lands in one adapter instead of
in every place attendance is touched. This is the same instinct as any anti
corruption layer: external models do not get to dictate internal ones, because
you will be living with your internal model long after the external one has
been revised.

Attendance is not a boolean

Zoom knows who joined. It does not know who they are in your system, and the
join records do not reliably line up with your registrations. People join from
a second device. They join late from a phone with a display name their parent
chose. They attend a session they never registered for because a colleague
forwarded the link.

Automatic matching handles most of it. The decision that mattered was building
a manual match path for the rest, rather than either guessing or dropping
them. A certification is a claim someone will make about themselves later,
possibly to an employer. It should not rest on fuzzy name matching being
confident enough.

Reminders as scheduled work, not delayed jobs

Reminders go out at seven days, twenty-four hours and one hour. The naive
version schedules three delayed jobs per registration at signup and hopes
nothing changes.

Things change. Sessions move, people cancel, someone registers ninety minutes
before a session starts and needs the one-hour reminder immediately or not at
all. The reliable shape is a background process that periodically evaluates
current state and asks what should be sent now, rather than a queue of
promises made under conditions that no longer hold. It costs more to build and
it survives a rescheduled event, which the delayed-job version does not.

Fifteen days, and the conversation about day sixteen

It shipped in about fifteen days as sole engineer and went into production for
real educator cohort trainings, iterated under live testing first: timezone
and ICS handling, mobile, and simplification of an admin UI that had grown to
match the domain rather than the person using it.

The part worth writing down is what happened next. The work had clearly
outgrown what was contracted, and there were two available responses: absorb
it quietly, or say so. I raised it in writing and we agreed a time-boxed
stabilisation window instead of an open-ended tail.

That is not a technical decision but it determined the outcome more than most
of the technical ones. Scope creep on a fixed engagement is rarely a single
conversation anybody refused to have. It is a series of small unremarked
absorptions, each individually reasonable, and the project ends in a place
neither side would have chosen deliberately. Naming it early is cheaper for
the client than discovering it late, and it is the difference between a
platform that gets finished and one that gets abandoned in a good-enough
state.

What I would tell the version of me on day one

The estimate was not wrong about the event tool. It was wrong about how many
systems had to agree for the event tool to be true. If a scope mentions
attendance, certification and reminders in the same sentence, the build is an
integration platform wearing a smaller job's clothes, and the honest estimate
is the one that prices the translation layer rather than the schema.

A portfolio chatbot that can drive the page it lives on

Somesh Bhardwaj — Fri, 13 Mar 2026 11:38:12 +0000

Most portfolio chatbots are a search box that answers in paragraphs. You ask
what someone has worked on, you get prose, and then you scroll to find it
yourself. The model knows the answer and the page it is sitting on stays
exactly where it was.

The one on this site can move the page. Ask to see incident work and it opens
the record filtered to incidents. Ask about a section and it scrolls there.
That is not a different model, it is the same tool-calling mechanism everyone
already has, pointed at the interface rather than at a knowledge base.

The key stays on the server, and that decides the architecture

The first real decision is not about the model. If the browser calls the model
provider directly, the API key is in the browser, and anybody who opens
devtools has your billing. Every "add AI to your site in five minutes" guide
that keeps the key client-side is teaching a mistake that only shows up on an
invoice.

So the request goes to a serverless function, which holds the key, attaches
the system instruction and the tool declarations, calls the model, and streams
the answer back. The client sends the conversation and nothing else. That
single constraint determines most of the rest of the design, and it is worth
accepting it up front rather than discovering it later.

It has a second effect that is easy to miss: because the system instruction is
assembled server-side, it can be changed without shipping a new bundle, and a
visitor cannot read it. The prompt is not secret, but it is also not something
to hand out with the JavaScript.

Five tools, and what they are for

Four of them do something to the page: search the work, open the record with
an optional category filter, scroll to a section, toggle the theme. One of
them, saveLead, records that a visitor wants to be contacted.

The declarations are the interesting part, because they are prompt
engineering wearing a schema. The description on openWork does not just say
what it does, it says when to reach for it and names the one argument value
that will not work. A tool whose description reads "opens the record" gets
called at the wrong moments; a tool that explains its own preconditions gets
called at the right ones. Most of the behaviour people attribute to the system
prompt is actually in the tool descriptions.

Retrieval that is deliberately not a vector database

Before the model answers, a retrieval step pulls the entries most relevant to
the question and puts them in the prompt. It is a substring matcher over the
record. There are no embeddings and no vector store.

For a few dozen entries with distinctive names, that is the correct
engineering. Embeddings would add an index to build, a service to depend on,
a rebuild step to forget, and a class of failure where the nearest neighbour
is confidently wrong. The substring matcher is inspectable, and when it
misses, it misses for a reason you can read.

What it does badly is fail silently. Rename a record or change the category
vocabulary and retrieval quietly returns less, and the bot gets vaguer rather
than erroring. Nothing in the response tells you this happened. That is
precisely why the retrieval layer has tests: not because the matching is
subtle, but because its failure mode is degradation rather than a stack trace,
and degradation does not page anyone.

The same reasoning covers the couplings between the bot and the site. The
categories in the tool declarations have to match the categories in the data,
and the section names it can scroll to have to match the sections that exist.
Both are asserted in tests, because the alternative is a chatbot confidently
offering to scroll somewhere that was renamed six commits ago.

The lead flow, and the gate before it

The tempting build fires saveLead the moment it has five fields. That
produces a form wearing a conversation, and it submits while the visitor is
still mid-thought.

Instead the model has to ask one closing question first, confirming there is
nothing else to add, and only then calls the tool. The reply that follows
carries a request ID, confirms where the transcript was sent, and gives an
address to follow up on with that ID, so the visitor leaves with a reference
rather than a hope.

That gate is one paragraph in the instruction and it is the difference between
a conversation that captures a lead and an interrogation that happens to be
written in sentences.

What I would keep

Tool calling for interface control rather than only for retrieval. The key on
the server, without exception. The smallest retrieval that works, with tests
around it precisely because it fails quietly. And a persona that positions the
work honestly: the site argues that AI is one tool inside systems work rather
than the identity, and a chatbot that oversold itself would contradict the
page it lives on.