Build an Agent that Never Sleeps

A background agent is a process that runs autonomously to enforce a goal or maintain a desired state, without requiring you to prompt it each time or wait for it to complete.

Unlike a chat agent where you give it a task and wait synchronously for a response, a background agent operates asynchronously in the background. You give it a goal—like "monitor my email inbox" or "keep this service healthy"—and it continuously works toward that goal, responding to events and making decisions on its own.

Key characteristics:

• Goal-oriented, not task-oriented: Instead of a single prompt, you define a vision of what you want the world or system to look like, and the agent enforces that vision.
• Event-driven: It can be triggered by external events (like a new email arriving) rather than waiting for your input.
• More durable and resilient: If something fails—an API call times out, a tool breaks—a background agent keeps working toward the goal, pausing and resuming as needed, rather than giving up like a synchronous chat agent would.
• Fire and forget: You set it up and walk away. It doesn't need you to verify each step or tell it when to act.

The real productivity unlock is that you're not the bottleneck anymore. It's like having a team member who knows their job, knows when to do it, and doesn't need constant direction—they just keep things in harmony with the state you defined.

An observe-decide-act loop is the core architecture for how a background agent processes work. Here's how it flows:

• Observe: When an event triggers the agent, it first observes the current state of the world or system you've given it. It gathers information about what's happening right now.
• Decide: Based on that observed state, the agent reasons about what action to take next to move toward its goal.
• Act: The agent executes that action, then loops back to observe again.

It's a continuous cycle—observe the state, decide what to do, do it, then repeat. This is similar to how most agent tool loops work today, but there are some key differences in how you build it for background agents:

• No tool calling: Unlike traditional agent SDKs, this harness doesn't use model-level tool calling. The agent still picks actions, but through a different mechanism.
• Can wait and suspend: Because it's running in the background with proper architecture, the agent can pause and wait for something (like user input or an external event) without consuming compute, then resume later. A chat agent can't really do that—it either completes or times out. But a background agent can suspend gracefully, like a person waiting for a response, and pick up where it left off days later if needed.

The loop keeps running as long as the agent hasn't reached its goal or hit a stopping condition, continuously responding to new events and adjusting its actions based on the current state.

A background agent is an intelligence system that can watch events, run on a schedule, or handle tasks without prompting. Unlike conversational or chat-based agents that require direct interaction, background agents can be given a goal and continue to work until they reach that goal. They can operate autonomously and reach out for help or approval when needed, without requiring constant supervision.

A background agent system is a combination of: 1. a harness (to control and validate agent actions), 2. infrastructure (to run the agent continuously), and 3. traditional agent capabilities (AI decision-making). These components work together to allow an agent to run indefinitely, heal itself, and accomplish tasks autonomously.

The harness protects the system by setting valiation checks and restrictions on what the agent can do. It can prevent the agent from performing destructive actions autonomously and require human approval for certain operations. It also enables deterministic behavior, such as ensuring the agent must reach out for help when specific conditions are met.

A background agent reaches out to humans in two main situations: 1. When it needs context or is uncertain about something and requires an answer to a question, and 2. When it wants to perform an action that requires human approval, where the harness locks down that action behind explicit human authorization.

When investigating a service issue, a background agent observes the alert that triggered the investigation, examines the current state of the service at the time the event occurred, reviews logs and events associated with the service, and continuously monitors for new events (such as health recovery notifications) that may affect the investigation.

They run on schedules or watch events without requiring prompts

Questions needing human context and approval requests that gate restricted actions

To prevent the agent from performing potentially destructive operations without oversight

Chat agents operate synchronously — they require a prompt and wait for a response in a back-and-forth process. Background agents are asynchronous and fire-and-forget; they can operate independently without requiring constant prompting and can continue working toward a goal without user interaction.

A chat agent will typically try alternative approaches and eventually return a failure message if it cannot complete a task. A background agent is more resilient and durable — it will continue attempting to achieve its goal over time, can pause and resume when needed, and persists through failures similar to how a person would keep working to solve a problem.

The observe-decide-act loop is an agent thinking framework where: (1) the agent observes the current state of its environment, (2) decides what action to take next based on that observation, and (3) executes that action, then repeats the loop. This continues until the agent achieves its goal or encounters a condition that requires it to wait or stop.

LLMs can hallucinate, so if you rely on an LLM to determine whether it needs approval for an action, it might incorrectly decide it doesn't need permission when it should. Deterministic logic like approval requirements should be enforced by the harness to ensure consistent, reliable behavior and maintain proper authority boundaries.

Background agents can suspend their state and wait indefinitely for input (like waiting days for a user response) without keeping compute resources or connections open. Traditional chat or coding agents typically cannot maintain state across extended periods — the process ends, connections close, or state becomes stale if the user doesn't respond quickly.

The agent picks actions without using tool calling at the model level

Since LLMs can hallucinate, they might also hallucinate whether approval is needed

They are more resilient and can pause, wait, and resume work toward the goal

Yes, the AI SDK is model-agnostic and uses the same code regardless of the model provider. You only need to change the model name in the configuration, and the rest of the code remains the same.

Inngest handles event-driven communication and durable execution between services, such as between the checkout service and the agent API.

While the AI SDK uses the same code structure regardless of which model you're using, you need to change the model name configuration where it's specified in your code. The SDK itself is model-agnostic, but the specific model identifier must be updated to reference Claude instead of OpenAI.

The three stages are: observe the current world (the state of the service), decide on the next action based on the current state, goal, and history of actions already taken, and act by executing the selected action (which is validated by the harness).

Model-directed actions are decisions the agent makes about which tools to use based on prompts. Harness-delegated actions are enforced at the code level by the harness itself, regardless of what the agent decides. For example, the harness can automatically provide state updates to the agent or restrict certain operations like rollbacks, even if the agent recommends them.

For an agent monitoring a service, the 'world' is the complete state of that service, including whether it's healthy, HTTP response codes it's returning, recent alerts, and any other information related to the service's current operational status.

The harness enforces policies set by the system designers to prevent potentially costly or dangerous operations. If rollbacks aren't allowed, the harness will intercept that recommendation and route it to a human for approval instead. This prevents the need to rely on prompting alone to control the agent's behavior, which can be unreliable.

The three core steps are: (1) Observe the current world state (automatically fed to the agent on every loop), (2) Decide what action to take next based on the current state, the agent's goal, and the history of actions already taken, and (3) Act by executing the selected action after the harness validates it. This observe-decide-act loop allows the agent to continuously monitor and respond to changes in the system it manages.

Observe, predict, and act

The harness validates permissions at the code level, not the agent

World state is the current condition of the service being monitored, while run state tracks the investigation progress and actions taken