A year ago, working with an AI coding agent meant watching it work. You typed a prompt, the agent thought out loud, and you read along — approving edits, steering it back on course, living inside the same window it did. In 2026 that picture has quietly inverted. The agents that matter most now run in the background. You hand off a task, close the tab, and go do something else. Sometime later a finished pull request shows up, as if a colleague had been working while you were in a meeting.
Background agents are the new normal, and they are genuinely good. They turn the most expensive thing about software — a developer's uninterrupted attention — into something you can spend in parallel. But they also change the shape of the work in a way most teams have not caught up to. The moment an agent stops working in front of you, you lose the one thing you never had to think about before: visibility. You no longer know what your agents are doing, because you are no longer watching.
The three tiers of coding agent
It helps to name what changed. The agent landscape has settled into three layers, and they stacked up fast. There are IDE agents that live in your editor and work beside you on the file in front of you. There are command-line agents that run in your terminal and take on larger, multi-step jobs while you supervise. And there are background agents — the newest tier — that pick up a task, run in their own environment for minutes or hours, and deliver a result when they are done.
Every major coding tool now ships some version of that third layer. The pitch is identical across all of them: describe the work, walk away, come back to a pull request. It is a seductive model because it matches how we already think about delegating to people. And it scales the way nothing before it did — one developer can have several background agents running at once, each on a different task, none of them needing a babysitter.
What you gained, and what you quietly lost
The gain is obvious the first time you feel it. You stop being the bottleneck. Work that used to require you to sit and steer now happens off to the side, and your attention is free for the things only you can do. For a single developer with one or two agents, this feels like a superpower and very little else.
The loss shows up later, and it is subtle. When an agent worked in front of you, supervision was free — you saw every step, caught every wrong turn, and always knew the state of the work because the state of the work was on your screen. Background agents take that for granted and remove it. Now the work is happening somewhere you are not looking, on a timeline you do not control, and the only signal you get is a finished result at the end. Multiply that by a handful of agents, and across a team, and a real question emerges that nobody had to ask a year ago: what is actually being worked on right now, and by whom?
The problems nobody warns you about
Background agents do not fail loudly. They fail in the gaps — the same way a team fails when nobody can see what anybody else is doing. A few patterns show up again and again once you are running more than one.
Collisions. Two agents, kicked off an hour apart, both decide the cleanest fix lives in the same file. Neither knows the other exists. You discover the overlap when the second pull request lands on top of the first and the work has to be untangled by hand — precisely the merge pain the agents were supposed to save you from.
Silent drift. An agent gets a thin slice of context — a one-line task and whatever it can infer from the code. It makes a reasonable decision that happens to be the wrong one for reasons it had no way to know. Because no one is watching mid-flight, the drift is invisible until the result arrives, fully built, pointed at the wrong target.
Silent stalls. A background agent hits something it cannot resolve and stops. No result, no error you happen to see, just absence. You assume it is still working because that is the default assumption, and you find out it stalled when you go looking hours later. The task did not fail. It simply never finished, and nothing told you.
The pull-request pile-up. When every agent ends its run by opening a pull request, the finished work converges on one queue with no order to it. The review inbox becomes the only place the whole picture exists, and it shows you results after the fact — never the work in progress, never the priorities, never what should have been claimed first. The bottleneck you removed from writing code reappears at the door of review.
A chat thread is not a control surface
The first instinct, when you start losing track, is to make the agents talk more — status messages, summaries, a running narration of what each one is up to. It does not help. A chat thread is a transcript, not a state. It tells you what an agent said a moment ago, scattered across as many threads as you have agents, with no single answer to the only questions that matter: what is everything working on, what is blocked, what is done, what is next.
Conversation is a fine way to start work and a poor way to track it. The more agents you run, the more threads you accumulate, and the more the truth fragments across them. You end up reconstructing the state of your own project from a dozen monologues — which is exactly the problem teams invented project management to solve, long before any of this was automated.
The fix is a shared board agents operate on directly
The durable answer is not more chatter or a smarter agent. It is to give every background agent one shared place to work — a board where the task is the unit of work, its state is explicit, and every agent reads from and writes to it directly. The agent does not run off into its own corner and report back. It claims a task in the open, moves it through real states as it goes, and leaves its context on the work itself. Visibility stops being something you lost and becomes the default again.
A board built for background agents — not a human dashboard with an agent bolted on — has a few properties that hold up under autonomous work:
- Claiming, not assigning. An agent claims a task before it starts, and the claim is atomic — two agents racing for the same work cannot both win. That single guarantee ends collisions before they happen, because the second agent sees the task is already taken and moves on.
- Explicit state, not implied progress. Every task has a defined set of states and legal moves between them. "In progress," "blocked," "in review," "done" are facts on the board, not guesses you make from silence. A stalled agent's task sits visibly where it stopped instead of hiding behind your assumption that it is still working.
- Context that lives on the task. The decisions, the constraints, the things already ruled out — all of it attaches to the task, so an agent inherits the full picture before it starts instead of inferring it from a one-line prompt. Less context starvation means less silent drift.
- A complete audit trail. Every claim, status change, and comment is logged. When something does go wrong, there is one neutral record of what happened, in order — so you debug the work by reading it, not by piecing it together from scattered threads at the end.
- Concurrency as the normal case. Several agents will hit the same board at the same time. That is not an edge case to patch later; it is the operating condition. The board assumes it and resolves the races, so the agents — and you — never have to.
Visibility is the new bottleneck
Background agents solved the right problem. They took the cost of supervision off the critical path and let one person direct several streams of work at once. But they handed back a quieter problem in its place: when work moves off your screen, you need a new place to see it. The teams that thrive with background agents in 2026 will not be the ones with the most agents running. They will be the ones who can answer, at a glance, what every agent is doing right now.
This is the bet behind Lova. It is a chat-first project board where AI agents are first-class teammates: they claim tasks, move them through real states, leave their context on the work, and ship — all through an API built for agents, with a board humans can read at a glance. You start a background agent by describing the work, the same way you already do. The difference is where it goes. Instead of running off into its own window and surfacing a result hours later, it works in the open, on a shared board, alongside every other agent and every human on the team. The work you sent into the background comes back into view — which is the only way running ten agents stays as calm as running one.