GUIDE

What does an AI agent need from a backend?

An AI agent backend is the server-side layer that runs an agent's reason-and-act loop and supplies what the model alone lacks: tools it can call, sessions that remember earlier turns, context management for long conversations, approval gates for risky actions, streaming to the user, and a record of every run. Powabase ships that runtime built in, next to each project's Postgres.

Last reviewed: September 24, 2026

What is an agent runtime?

Most agents follow the ReAct pattern, short for reason and act, described by Yao et al. in 2022. The model reads the conversation, decides whether it needs a tool, and if so emits a tool call. The runtime executes that call, appends the result, and asks the model again. The loop ends when the model answers in plain text. The loop fits in a few dozen lines of code, and most of the engineering goes into the runtime around it. A good runtime caps the number of steps so a confused model can't spin forever, and forces a final answer on the last one. It runs read-only tool calls in parallel and write calls one at a time. It notices when the model repeats the same call with the same arguments and stops the run. It retries transient model errors, records token usage, and survives a client that disconnects halfway. An agent framework gives you the loop inside your own process, and running it in production stays your job. A backend runs the loop for you, next to your data. For that trade-off in detail, see Powabase vs a LangChain stack.

What tools does an AI agent need?

Tools are how an agent acts on the world, and they come in three kinds. Built-in tools cover common needs, such as reading and writing your database, calling an HTTP API, running code in a sandbox, reading and writing stored files, and searching or scraping the web. Custom tools call your own HTTP endpoints, described by a name, a description, and a JSON Schema for the arguments, so the model can use your business logic without seeing your code. MCP servers expose tools over the Model Context Protocol, an open standard where a client lists a server's tools with tools/list and calls them with tools/call, so one integration works across many agents. Good tool design matters more than tool count. Write precise descriptions and tight schemas, and keep permissions narrow, so a database tool reaches only the schemas and tables the agent needs. Point HTTP tools at fixed endpoints rather than letting the model choose any URL. Retrieval is a tool too. A knowledge-search tool lets the agent search your documents when it decides it needs them, and search again with a better query, instead of taking whatever one up-front search returned.

  • Built-in: database read and write, HTTP, code execution, storage, web search, web scraping
  • Custom HTTP tools pointed at your own endpoints
  • MCP servers discovered at the start of each run
  • Knowledge-base search the agent calls when it needs context

How do agents remember past conversations?

An agent has two kinds of memory. Short-term memory is the session: the ordered history of a conversation, including each user message, the agent's replies, every tool call, every tool result, and the token usage per run. On the next message, the backend reloads that history and rebuilds the prompt, so the agent picks up where it left off, even days later. Long-term memory is knowledge that outlives one conversation: user preferences, facts learned along the way, and summaries of past work. It is usually stored as rows with embeddings and recalled by meaning when it becomes relevant. Where both live matters. If sessions sit in a Redis cache, memories in a vector store, and users in Postgres, you have three systems to back up and keep in sync. Put sessions, memories, and app data in one Postgres and you can query a user's history with SQL under the same access policies as everything else. When a user asks you to delete their data, one transaction removes all of it. Agent memory in Postgres walks through that design, and what a vector database is covers the recall side.

What happens when a conversation outgrows the context window?

Every model has a context limit, and agents reach it faster than chatbots because tool results are long: a database query or a scraped page can add thousands of tokens in one step. The backend has to handle this without the user noticing, usually by compaction. Before each model call, the runtime estimates the prompt's size. If it is close to the limit, it first prunes old tool results, replacing them with short placeholders while keeping the most recent turns intact. If that isn't enough, it summarizes the older part of the conversation with a small, cheap model and continues from the summary. If the model still rejects the prompt as too long, the runtime compacts and retries rather than failing the run. The opposite problem is an answer cut off by the output limit, which the runtime handles by asking the model to continue where it stopped. These details decide whether an agent can work through a long task, such as reviewing a large document set or a multi-hour support thread. Long-running agents on Postgres covers the durable-state side of the same problem.

How do you keep a human in the loop?

Some actions shouldn't happen just because a model decided they should: refunding a payment, emailing a customer, deleting records, or changing production data. An agent backend handles this with hooks at fixed points in the run, such as before a tool call, after a tool call, and before the final answer. Most teams need only three kinds of hook. A rule hook checks the tool arguments against patterns and denies matches, such as any SQL containing DROP. A webhook hook sends the event to your own policy service, which can allow the call, deny it, or rewrite its arguments or output, for example to redact personal data. An approval hook pauses the run, tells your app which tool the agent wants to call and with what arguments, and waits for a person to approve or reject. On approval the tool runs. On rejection the agent is told no and chooses another approach. A timeout stops a forgotten approval from holding the run forever. Scope approvals to the risky tools only. Asking a person to approve every search makes the agent too slow to use, and people start approving without reading.

Why stream agent runs?

An agent run can take seconds or minutes, so a request that returns only at the end feels broken. Streaming fixes this by sending events as the run happens. Server-Sent Events (SSE) is the common choice: a one-way stream of named events over a normal HTTP response, which browsers support natively and proxies generally pass through. A good agent stream carries more than text. It announces each step, each tool call with its arguments, each tool result, the answer's tokens as they are generated, any approval request, and a final completion event with the session ID and usage. That lets your UI show "searching the knowledge base" or "running a query" while the agent works, and lets you render citations next to the answer. The backend also has to handle the user who closes the tab. It should stop the agent so it doesn't keep spending tokens, and save the partial run so the session history stays complete.

When do you need more than one agent?

Start with one agent and a few good tools. Anthropic's guidance on building agents makes the same point: the most successful systems use simple, composable patterns, and add complexity only when it clearly helps. Reach for multiple agents when one prompt can't cover every domain well, when a task splits into stages, or when you want independent views of the same input. Most multi-agent setups take one of three shapes. A supervisor agent reads each request and delegates to a specialist, such as billing or technical support, then combines what they return. A sequential pipeline passes each agent's output to the next, for example extract, then analyze, then write. A parallel fan-out sends the same input to several agents at once and merges their answers. Each pattern needs the backend to track child runs, share a cancel signal, limit delegation depth, and keep one record of the whole thing. And when the order of steps is known in advance, you may not need agents to coordinate at all. A workflow with agents as steps gives you a fixed path with AI where it helps.

How Powabase does it

How Powabase does it

We run the agent runtime inside each Powabase project, next to your Postgres, auth, and documents. You define an agent with a model, a system prompt, tools, and knowledge bases, then call POST /api/agents/{id}/run/stream and receive the whole run as Server-Sent Events. Sessions, runs, and tool calls are stored in the project's database, so you can query them with SQL like any other table.

  • A ReAct loop with up to 25 steps by default, parallel read-only tools, doom-loop detection, and automatic retries
  • Eight built-in tools, your own HTTP tools, and MCP servers discovered at the start of each run
  • Sessions that rebuild history on every turn, with automatic context compaction when a conversation grows
  • Hooks at six lifecycle events: rule policies, webhooks that can rewrite inputs and outputs, and human approval gates
  • SSE events for steps, tool calls, tool results, tokens, reasoning, approvals, and completion
  • Orchestrations with supervisor, sequential, and parallel strategies, and workflows that call agents as steps
  • Knowledge-base search as a tool, with citations streamed back to your UI

What an agent backend has to provide

  • Runtime

    What it involves:
    ReAct loop, step limits, parallel tools, loop detection, retries
    Powabase:
    Built in

  • Tools

    What it involves:
    Built-in actions, your HTTP endpoints, MCP servers
    Powabase:
    Eight built-in tools, custom HTTP tools, MCP

  • Retrieval

    What it involves:
    Search over your documents as a tool
    Powabase:
    Knowledge-base search with vector, BM25, hybrid, and tree search

  • Sessions and memory

    What it involves:
    Conversation history, long-term recall, one place to store it
    Powabase:
    Sessions and runs in the project's Postgres, pgvector for recall

  • Context management

    What it involves:
    Pruning and summarizing when the window fills
    Powabase:
    Automatic compaction and retry

  • Human oversight

    What it involves:
    Policies, webhooks, approval before risky tools
    Powabase:
    Rule, webhook, and approval hooks

  • Streaming

    What it involves:
    Live events for steps, tools, tokens, approvals
    Powabase:
    Server-Sent Events

  • Multi-agent

    What it involves:
    Delegation, pipelines, fan-out
    Powabase:
    Supervisor, sequential, and parallel orchestrations

FAQ

Questions.

It is the server-side layer that runs an agent's loop and gives it tools, memory, and oversight: executing tool calls, storing sessions, managing the context window, pausing for human approval, streaming progress, and recording each run. Powabase provides one on every project, next to the project's Postgres.

No. A framework gives you the loop as a library, and hosting it and storing its state stay your job. A backend with a built-in runtime, such as Powabase, runs the loop for you and stores sessions in your database, so you define the agent and call an API.

ReAct (reason and act) is the pattern most agents use: the model reasons about the task, calls a tool, reads the result, and repeats until it can answer. The runtime around it enforces step limits, runs tools, and stops loops that repeat the same call.

Store session history as ordered runs and long-term memories as rows with embeddings, ideally in the same Postgres as your app data. Then one set of backups and access policies covers everything, and you can query or delete a user's history with SQL.

Yes. The Model Context Protocol lets an agent discover a server's tools with tools/list and call them with tools/call. Powabase agents connect to MCP servers over HTTP at the start of each run and use their tools alongside built-in and custom ones.

Add an approval hook that fires before a specific tool, such as a database write. The run pauses and streams an approval request, and your app calls an approve endpoint with yes or no. Powabase supports this with a configurable timeout.

Use Server-Sent Events. Powabase's stream endpoint sends events for each step, tool call, tool result, and token, plus approval requests and a completion event with the session ID. Proxy the stream through your server so the service key stays off the client.

Docs

Sources

  1. https://arxiv.org/abs/2210.03629: ReAct: interleaving reasoning traces and actions in language models (Yao et al., 2022).
  2. https://modelcontextprotocol.io/specification/2025-06-18: The Model Context Protocol, including tool discovery with tools/list and invocation with tools/call.
  3. https://www.anthropic.com/engineering/building-effective-agents: The distinction between workflows and agents, and the advice to start with simple, composable patterns.
  4. https://html.spec.whatwg.org/multipage/server-sent-events.html: Server-Sent Events: a one-way stream of named events over HTTP with native browser support.
  5. https://docs.powabase.ai/concepts/agents-tools: Powabase ReAct loop and limits, eight built-in tools, custom HTTP tools, MCP, sessions, context compaction, hooks, and human approval.
  6. https://docs.powabase.ai/concepts/orchestrations-concept: Powabase supervisor, sequential, and parallel orchestration strategies and the delegation depth limit.