Skip to content
Nolli
Request a demo
Nolli Learn

Guide · Equip

Sidekick agents vs. background agents: which work should each do?

Sidekick agents work with you in real time; background agents run on their own. Which work suits each, how approvals work, and how to keep them safe.

The short answer

A sidekick agent works with a person in real time, inside that person’s tools: the person asks, the agent answers or acts, and the person steers and decides. A background agent works on its own: a schedule or an event starts it, it works for minutes or hours, and it reports back or asks for approval when it needs a decision. Give sidekicks varied, judgment-heavy work that someone is doing now, and give background agents recurring or long jobs with clear checkpoints.

By Nadi Haque, Founder, NolliUpdated 10 min read

Key takeaways

  1. A sidekick works with a person in real time, and the person steers and decides. A background agent starts on a schedule or an event, works for minutes or hours, and reports back or asks for approval when it needs a decision.
  2. Choose by the work: how often it happens, how long it takes, how much judgment it needs along the way, how soon the answer is needed, and what a mistake costs.
  3. A background agent needs, in advance, the controls a sidekick gets from the person watching: specific approvals, stop rules, budgets and logs. Prove it in shadow mode before it acts alone.

What are sidekick agents and background agents?

A sidekick agent works with a person in real time, inside the tools that person already uses. The person asks, the agent answers or acts, and the person steers and decides at every turn. Chat assistants, copilots and the agents built into code editors work this way.

A background agent works on its own. A schedule or an event starts it, such as 07:00 every Monday or a new support ticket. It works for minutes or hours, reports back when it’s done, and asks a person when it needs a decision. A person can also start one and walk away. Depending on the vendor, you’ll see them called ambient, cloud or autonomous agents.

What separates the two is who is there while the work happens. With a sidekick, a person sees every step and catches mistakes as they go. With a background agent, nobody is watching, so the checks, limits and approvals that person would supply have to be built in ahead of time. Harrison Chase of LangChain describes the shift as moving from “human-in-the-loop” to “human-on-the-loop.”

QuestionSidekick agentBackground agent
Who starts itA person, with a requestA schedule, an event, or a person handing off a job
How long it worksSeconds to minutes, while the person waitsMinutes to hours, while people do other work
Where it worksIn the person’s own tools: a chat, a document, the CRM, the code editorInside the team’s systems, with the access its brief allows
Who steersThe person, at every turnA brief written in advance: the goal, the limits, when to stop
Who decidesThe person, as the work happensThe agent, within its limits. A person decides anything outside them
How it reports backIn the conversation, step by stepIt notifies, asks or requests a review where the team works, and keeps a log
Best forVaried, judgment-heavy work someone is doing nowRecurring or long jobs with clear checkpoints
ExampleDrafting a deal desk summary with the analystPreparing the Monday revenue review by 09:30
Figure 1. Sidekick and background agents, side by side. The examples come from the illustrative revenue team in Nolli’s product demo.

What do sidekick and background agents look like at work?

Take two jobs from the revenue team in Nolli’s product demo, an illustrative company:

  • A deal desk sidekick. The deal desk handles about 30 approval requests a week. With a sidekick open beside the deal, the analyst asks for a summary. It runs the team’s three standard checks and drafts the approval summary. The analyst questions one figure, edits a line and makes the call: approve the deal, or send it to Sales leadership.
  • A revenue review background agent. Every Monday at 07:00, an agent starts on the weekly revenue review. It gathers updates from 14 account threads, reconciles the figures and builds the deck, ready for the revenue ops lead to check by 09:30. When figures conflict, it hands them to the lead. It never sends anything to leadership.

The same split shows up in research and in today’s products:

  • Customer support. In a study of 5,172 customer-support representatives, an AI assistant that suggested replies in real time raised the number of chats resolved per hour by 15% on average, Erik Brynjolfsson, Danielle Li and Lindsey Raymond report. The representatives stayed responsible for each conversation and could ignore or edit any suggestion. That is a sidekick.
  • Business software. Microsoft describes autonomous agents in Copilot Studio that respond to events without waiting for a prompt and run continuously in the background.
  • Ambient agents. Chase defines ambient agents as agents that listen to a stream of events and act on them, potentially several at once. His team’s first example was an email assistant.
  • Coding. Cursor, OpenAI and GitHub each offer both modes. GitHub describes the two: assistants in the editor that pair with a developer as they work, and its Copilot cloud agent (formerly Copilot coding agent), which works independently in the background. Cursor launched background agents in preview in May 2025 and now calls them Cloud Agents. They work for minutes or hours in the cloud and attach videos, screenshots and logs to the pull request they open. OpenAI’s Codex cloud tasks keep running while your computer is asleep.

Most of these background agents finish by handing something to a person: a pull request to review, a draft to approve or a question to answer.

Which work suits a sidekick, and which suits a background agent?

First, check that the step needs an agent at all. Many steps should be deleted or run as plain code; see the four buckets. For the steps that do, five questions point to the mode:

  1. How often does the work happen? Work that repeats on a schedule, or with every event of one kind, can be set up once and run in the background. Work that is different every time suits a sidekick.
  2. How long does it take? A person can wait seconds or a few minutes. Nobody should sit and watch an hour-long job. People also accept longer waits from background work, Chase observes, which leaves the agent free to work more carefully.
  3. How much judgment does it need along the way? If every step needs a person’s call, keep the person steering. If the judgment falls at a few known points, such as two figures that disagree, those points become approvals in a background run.
  4. How soon is the answer needed? Someone on a customer call needs it now, from a sidekick. A deck due at 09:30 can be built before anyone arrives.
  5. What does a mistake cost? This sets how much checking the work needs, whichever mode it runs in. A sidekick’s mistakes pass in front of a person. A background agent’s don’t, unless you build in checks, so the costlier the mistake, the more of its work should stop for review. Decisions such as approving a discount stay with a person either way.

Two of the questions do most of the sorting: how much judgment the work needs along the way, and how soon the answer is needed.

Judgment along the way →
SidekickA person leads and decides as the work happens.
  • A deal desk summary, with the analyst
  • A customer’s question, on a live call
A person leads, agents helpThe thinking stays with a person. The legwork goes to the background.
  • The quarterly board narrative
  • Prep for a renewal negotiation
Background, on a triggerStarts when something happens, so the result is ready when a person looks.
  • Pre-check each new deal request
  • Draft a first reply to each ticket
Background, on a scheduleFinishes before it’s needed. People decide at set points.
  • The Monday revenue review, by 09:30
  • Match last night’s invoices
Time until it’s needed →
Figure 2. Which mode fits the work? Illustrative examples. What a mistake costs sets how much checking each one needs, wherever it sits.

What does a background agent’s run look like?

Here is the Monday revenue review again, run by a background agent. Its brief fits in four lines: have the deck ready by 09:30; read the sources but change none of them; hand any conflict to the revenue ops lead; never send anything to leadership.

  1. 07:00
    Background agentStarts on scheduleReads 14 account threads, #revenue-updates, Salesforce and the forecast workbook. It can read all of them and change none.
  2. 07:35
    Background agentReconciles the figuresMatches closed-won deals to the workbook and finds two conflicts.
  3. 07:40
    Background agentAsksAsks one questionSends the lead the conflict that changes the total, then keeps working.
  4. 08:10
    Background agentBuilds the deckFills slides 2–4 from the workbook’s summary tab and marks the second conflict on slide 3.
  5. 08:40
    Revenue ops leadAnswersSettles the conflictFrom their phone: “Count the Halden renewal. The contract was signed Friday.”
  6. 08:45
    Background agentNotifiesHands over the deckUpdates slide 2, logs the answer and posts that the deck is ready, with one item to check.
  7. 09:30
    Revenue ops leadReviewsReviews the deck15 minutes on the flagged items, not every cell.
  8. 10:35
    Revenue ops leadDecidesWrites the recommendation25 minutes, then sends it to leadership by 11:00. Only the lead sends anything to leadership.
Figure 3. One Monday morning with a background agent. An illustrative run. The agent works for under two hours; the lead spends about 40 minutes.

The lead’s morning shrinks to one answer sent from their phone, 15 minutes of review and 25 minutes writing the recommendation: the parts that need their judgment. Before the agent got this job, it ran in shadow mode for four Mondays, building the deck alongside the team and sending nothing.

How do people work with a background agent?

A background agent reaches people in three ways, which Chase calls notify, question and review:

  • Notify. Flag something a person should know, without acting on it: the deck is ready, with one item to check.
  • Question. Ask for what the agent doesn’t know, instead of guessing: should the Halden renewal count this week?
  • Review. Let a person approve, edit or send back the agent’s work before anything goes out: the lead reviews the deck before writing the recommendation.

Send these where people already work. Chase’s team started in Slack, where everyone already was, then found it easy to lose track of the notifications. So they built an agent inbox, modeled on an email inbox and a support ticket queue, that shows every open request in one place.

Make every request count. When requests come too often, people start clicking “approve” without reading. Anthropic’s engineers call this approval fatigue, and found that letting Claude Code work freely inside set boundaries cut its permission prompts by 84% in their own use. Ask only where a decision matters, and make each request specific enough to decide on the spot:

Revenue review preparerBackground agent · to the revenue ops lead · Monday, 07:40

Count the Halden Logistics renewal ($124,000) in this week’s total?

Why you
Figures conflict, and your rule sends conflicts to you.
What I found
The forecast workbook shows it closed on Friday. Salesforce still shows it open.
What I checked
Every other closed-won deal. The one other mismatch doesn’t change the total, so it’s marked on slide 3.
What it changes
The total on slide 2, by $124,000.
  • Count it
  • Leave it out
  • Show me the records

No answer by 09:15? I’ll leave it out, mark slide 2 as provisional and list it in the 09:30 summary.

Logged with this run: the sources I read, the checks I ran and your answer.

What makes it a good request

  1. One decision, asked as a question.
  2. Why this person, and the rule that sent it to them.
  3. The evidence, and what the agent has already checked.
  4. What the answer will change.
  5. Clear answers, a deadline and a safe default.
  6. A record of the decision.
Figure 4. A specific approval request. The 07:40 question from figure 3. Illustrative; the same request works in a chat app or an agent inbox.

Route requests by risk, too. One automation at Cursor rates the risk of every pull request, approves the low-risk ones itself and assigns up to two reviewers to the rest. It summarizes its decisions in Slack and logs them, so the team can audit its work. In business terms: the agent finishes the routine cases and sends the unusual ones to the person who owns them, with a record of both.

What can go wrong with background agents, and how do you control them?

A sidekick’s mistakes happen in front of someone. A background agent’s happen while nobody is looking. Three risks follow:

  • Silent failure. The agent skips a source it couldn’t reach, stops early or reports success on unfinished work. Anthropic’s engineers saw agents on long coding jobs notice that progress had been made and declare the whole job done.
  • Runaway cost. An agent that loops, retries or fires on every event can spend far more than anyone planned. Anthropic warns that autonomy brings “higher costs, and the potential for compounding errors.” Triggers multiply both: Cursor’s code-review agent, Bugbot, is triggered thousands of times a day.
  • Stale context. The agent works from what it read at 07:00 and from rules written months ago. If the workbook changes at 08:50, or the discount policy changes in March, it carries on with the old version unless its sources and brief are kept current.

The controls stand in for the person who would have been watching. Build them into the agent’s harness, where they are enforced, rather than only into its instructions:

  • A brief: the goal, the deadline, what it may read and change, and what it must never do.
  • Stop rules: limits on time and steps, and the cases where it must stop and ask.
  • A budget for each run and each month, with an alert before it runs out.
  • The least access that does the job. Read-only wherever possible.
  • Checks on what can start it, so a fake email or event can’t.
  • A definition of done that it checks before it reports success.
  • A log of every trigger, source, step, decision and approval.
  • An owner who hears when a run fails, stalls or misses its deadline.
Figure 5. Before a background agent runs on its own. Agree on each one with the agent’s owner before the first run.

Vendors point the same way. Microsoft advises least-privilege access, checks that each trigger is genuine, and detailed logs of triggers, decisions and actions. GitHub builds limits into its cloud agent: every session stops after at most 59 minutes, the agent can push to only one branch, a person must review and merge its pull requests, and the person who asked for a pull request can’t approve it.

Then prove the agent before it acts alone. Run it in shadow mode for a full cycle of the work, and give it more responsibility one step at a time, through graduated autonomy. Once it is live, watch it like any production system; see AI agent observability and governance.

How do sidekick and background agents work together?

Most real work uses both, with handoffs in both directions:

  • From sidekick to background. The deal desk analyst spots a discount error on a multi-currency deal and asks the sidekick to check every multi-currency deal this quarter. Nobody needs to watch that job, so it goes to a background agent, which reports back by morning. Coding tools already work this way. OpenAI’s Codex moves a task from the editor to the cloud with the conversation’s context, and GitHub’s cloud agent carries over the context of the chat that started it.
  • From background to sidekick. When the revenue review agent hands back a conflict, the lead picks it up with a sidekick that can see what the agent read, checked and found. Codex lets developers bring a cloud task’s changes back to their own machine and carry on with the same context, and Cursor lets them take control of the agent’s remote desktop to finish the job.
  • From sidekick to background, over time. Work often graduates. The deal desk summary starts as a sidekick while the team learns what a good summary looks like. Once the drafts pass the team’s checks in shadow mode, the same skill can run in the background, drafting each summary as the request arrives, while the analyst still approves every deal.

So for each workflow, start with one question: does a person need to be there while the work happens? Where they do, give them a sidekick. Where they don’t, let an agent work in the background, and bring people in only for the decisions that are theirs.

Questions people ask

What is the difference between an AI copilot and an AI agent?

A copilot, or sidekick, is one way an agent can work: with a person in real time, where the person asks, the agent answers or acts, and the person decides. An agent can also work in the background, started by a schedule or an event, and check in only when it needs a decision. The useful question is whether a person needs to be there while the work happens.

Is a background agent the same as an autonomous agent?

Not quite. A background agent runs without anyone watching, but it can still stop to ask a question or wait for approval. How much it may do alone is a separate choice. Microsoft, for example, calls its event-triggered agents in Copilot Studio autonomous, and still advises having a person approve sensitive actions.

What is an ambient agent?

Ambient agent is LangChain’s name for a background agent that listens to a stream of events, such as incoming email, and acts on them without waiting for a prompt. Harrison Chase of LangChain describes three ways it involves people: it notifies them, asks them a question, or asks them to review an action before it happens.

Where should a background agent ask for approval?

Where the approver already works, such as Slack or Teams, or in an agent inbox once many agents need decisions. LangChain started in Slack and built an inbox when notifications became easy to lose track of. Wherever it lands, each request should ask for one decision, show the evidence and say what happens if nobody answers.

How long should a background agent run before it stops?

Set limits on time, steps and spend for every run, based on what a normal run takes in shadow mode, and alert the agent’s owner when a run hits one. GitHub, for example, stops every Copilot cloud agent session after at most 59 minutes and lets teams set a shorter limit.

Should we start with a sidekick or a background agent?

Let the work decide. A recurring job with clear checkpoints, such as a weekly report, can go to a background agent once it has proven itself in shadow mode. Varied, judgment-heavy work belongs with a sidekick. A workflow can also start with a sidekick while the team learns what good looks like, then move its repeatable part to the background.

Sources

  1. Harrison Chase. “Introducing ambient agents.” LangChain, January 14, 2025.
  2. “What are background agents?” Cursor, accessed October 4, 2026.
  3. “Design autonomous agent capabilities.” Microsoft Learn, Copilot Studio docs, accessed October 4, 2026.
  4. Harrison Chase. “UX for Agents, Part 2: Ambient.” LangChain, August 2, 2024.
  5. Erik Brynjolfsson, Danielle Li and Lindsey Raymond. “Generative AI at Work.” The Quarterly Journal of Economics, February 4, 2025.
  6. “About GitHub Copilot cloud agent.” GitHub Docs, accessed October 4, 2026.
  7. “Research, plan, and code with Copilot cloud agent.” GitHub Changelog, April 1, 2026.
  8. “Simplified Pricing, Background Agent and Refreshed Inline Edit.” Cursor changelog, version 0.50, May 15, 2025.
  9. “Using Codex Cloud.” OpenAI Help Center, accessed October 4, 2026.
  10. David Dworken and Oliver Weller-Davies. “Beyond permission prompts: making Claude Code more secure and autonomous.” Anthropic, October 20, 2025.
  11. Jack Pertschuk, Jon Kaplan and Josh Ma. “Build agents that run automatically.” Cursor, March 5, 2026.
  12. Justin Young. “Effective harnesses for long-running agents.” Anthropic, November 26, 2025.
  13. Erik Schluntz and Barry Zhang. “Building effective agents.” Anthropic, December 19, 2024.
  14. “Risks and mitigations for GitHub Copilot cloud agent.” GitHub Docs, accessed October 4, 2026.
  15. “Features.” OpenAI, Codex IDE extension docs, accessed October 4, 2026.