---
title: "We need background agents"
date: 2026-05-07
author: "Daniel Henneberger"
description: "The next leverage point for engineering teams isn't a smarter chat window. It's a fleet of patient, scoped agents working overnight."
tags: ["agents", "automation", "platform"]
cover: "/blog/we-need-background-agents.svg"
---

For a year now, the conversation around AI in software has been dominated by **the assistant**: a chat window that helps you while you're already at the keyboard. That's useful. It is also, on its own, a profoundly limited mental model.

The next leverage point isn't a smarter chat window. It's **background agents** — patient, scoped, observable workers that run when nobody is watching, and that ship pull requests by morning.

## What we mean by "background agent"

A background agent is software that:

1. **Runs on its own clock**, not on yours.
2. **Owns a narrow contract** — a specific outcome, not a general-purpose assistant.
3. **Produces reviewable artifacts** — a PR, a ticket update, a Slack draft — never silent state changes.
4. **Stops on uncertainty** rather than hallucinating forward.

Read those again. Each one is a refusal of how today's tools work.

> Foreground tools are interruptive by design. Background agents are the opposite — they are quiet until they have something worth showing you.

## Why now

Three things changed in the last 18 months:

- **Long-context models** that can hold a non-trivial slice of a repo and its history at once.
- **Tool use** APIs that make it routine to chain reads, writes, and shell calls.
- **OIDC + scoped credentials** that let an agent act on infra without a human handing it long-lived secrets.

Put those together and the agent is no longer a research demo. It's a deployable unit. A junior engineer with no working memory but unlimited patience.

## Where Mari fits

Mari's whole bet is that documentation is a *background-agent-shaped* problem. Consider:

```ts
// today: every team
const docsAreStale = stalenessOf(docs) > 30 // days
const onCallLearnsTheHardWay = true
```

The work is repetitive, low-glamour, and — critically — *bounded*. There's no ambiguity about what "the runbook for service X is wrong" means. There's a ground truth in the code, the PRs, and the Slack threads. An agent can find the gap, draft the patch, open the PR, and get out of the way.

That's a job description.

## What we still need to figure out

Background agents demand a different operational model:

- **Cost telemetry**: agents consume tokens; teams need budgets the way they have AWS budgets.
- **Failure modes**: silent drift is worse than a noisy crash. Every agent must emit a heartbeat.
- **Authority**: which agents can merge? Which can only suggest? This needs to live in code, reviewed like any other policy.
- **Provenance**: when a doc says X, the reader must be able to trace it back to the source the agent used.

The last two stopped being roadmap and became the product. Mari keeps a record of everything your AI writes: every fact gets a source, an owner, and a sign-off, and fixes land as PRs that wait for your review. Authority is the sign-off. Provenance is the record. The first two we'll keep writing about.

If you'd rather see it live, [book a demo](https://calendly.com/d/dtn2-w7x-bbm/mari-guru-intro), or open an issue on [GitHub](https://github.com/MariHQ/mari) and pull on the thread.