Claude AI Agents: What to Build So You Stop Re-Prompting

What a Claude agent is (and isn't)

A Claude agent is an Anthropic model running in a loop with tools: you describe the tools, Claude decides which to call, your code runs them and hands back results, and the loop repeats until the task is done. Four different things get called a "Claude agent," though, and the search results for that phrase blur all four together.

The chat product is a conversation that forgets when the session ends. Claude Code is a CLI for a developer sitting at a terminal against a local filesystem. The Messages API with tool use is the actual building block: you define tools with an input_schema, Claude returns a stop_reason of tool_use with the arguments it wants, your code runs the operation and sends back a tool_result block carrying the matching tool_use_id. The loop runs until Claude stops asking. Claude Managed Agents is Anthropic's hosted version of that loop, with the sandbox, tool execution, and session state handled for you.

If you want the general shape first, what an AI agent actually is covers it. Here the question is which of the four you build on.

• Messages API + tool use · What you build: Your own agent loop, tool handlers, retry logic, and state store · Best for: Full control over what the agent can touch and how state is kept · Main constraint: You own the loop, the sandbox, and the failure handling
• Claude Managed Agents · What you build: Agent, environment, and session config; you send events and read the stream · Best for: Long-running or asynchronous tasks where you don't want to run infrastructure · Main constraint: Beta, and sessions persist state server-side
• Claude Code CLI · What you build: Prompts and local config for a terminal session · Best for: A developer working interactively on a codebase · Main constraint: Interactive by design, not a system that runs unattended
• Platform-built agent · What you build: The workflow, plus the apps the agent builds to run it · Best for: Agents that act on business systems under permissions and audit · Main constraint: You work inside the platform's app model

When an agent over Claude actually helps

An agent earns its place when the work spans several systems, needs judgment at one or two points, and has to keep running when nobody is watching. Five cases where that holds.

Contract review gets faster because the whole document fits in one pass. An agent pulls the agreement from Gmail or a Drive folder, reads it end to end, and writes the extracted terms somewhere durable. A regex pipeline cannot tell you that clause 14.3 quietly caps liability at one month of fees.

Support triage stops depending on who's online. The agent reads the inbound ticket, checks account context, classifies severity, and posts the ones that need a human into a Slack channel with the reasoning attached. Volume classification is the part worth automating. The escalation judgment is the part worth a model.

Code review catches the class of problem linters miss. An agent reads a diff, checks it against the team's conventions in Notion, and comments on the pull request. Style is a linter's job. "This migration will lock the table" is not.

Research synthesis produces something you can query later. An agent reads a set of filings or vendor responses, extracts a consistent structure from each, and writes rows into a database rather than a summary into a chat window. The structure is what makes it useful in three months.

Multi-step operational work runs without a person holding the thread. Reconcile, check, draft, route, escalate. These are agentic workflow patterns where the value comes from the steps connecting reliably, and a chat session is the wrong container because it ends.

How do you use Claude as an AI agent?

You call the Messages API with a tools array, execute the tool calls Claude returns, and send the results back until it stops asking. Everything below is what that costs you in practice.

The Anthropic API in 200 words

Base URL is https://api.anthropic.com. Authenticate with x-api-key, or with Authorization: Bearer <token> if you're using Workload Identity Federation. Two headers are mandatory on every raw HTTP call: anthropic-version (for example 2023-06-01) and content-type: application/json. Omit the version header and the request fails with a valid key.

Core endpoints: POST /v1/messages for the model call, POST /v1/messages/batches for asynchronous bulk work, POST /v1/messages/count_tokens to price a request before sending it, and GET /v1/models. The Agents, Sessions, and Environments APIs that make up Managed Agents are in beta and require the managed-agents-2026-04-01 beta header on every request, per Anthropic's Managed Agents documentation.

Anthropic's term for the mechanism is tool use. A minimal client tool:

curl https://api.anthropic.com/v1/messages \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "content-type: application/json" \
-d '{
"model": "claude-sonnet-5",
"max_tokens": 1024,
"tools": [{
"name": "get_contract_record",
"description": "Fetch a stored contract record by id.",
"input_schema": {
"type": "object",
"properties": {"contract_id": {"type": "string"}},
"required": ["contract_id"]
}
}],
"messages": [{"role": "user", "content": "Summarize contract c_8812."}]
}'

Official SDKs cover Python, TypeScript, Go, Java, C#, PHP, and Ruby, and they set the headers for you. Getting from this call to something that survives production is a separate exercise: see taking an agent from prototype to production.

Pros and cons of the Anthropic API

The good parts are real. Tool use is well specified, strict: true on a tool definition makes Claude's calls match your schema exactly, and prompt caching is good economics for agents that re-read the same documents. Now the parts that will bite you.

input_tokens is not your total input. The field counts only tokens after your last cache breakpoint. Total input is cache_read_input_tokens + cache_creation_input_tokens + input_tokens. Anthropic's docs give the example: a 200k-token cached document plus a 50-token question reports input_tokens: 50. Build a cost dashboard on the naive field and you under-report by orders of magnitude on exactly the workload you most need to watch.

Adding tools injects a system prompt you pay for. Between 286 and 804 tokens per request, depending on model and tool_choice. Claude Opus 5 charges 286 for auto or none and 406 for any or tool. Opus 4.7 is the expensive end at 675 and 804. Multiply by loop iterations, then by runs per day.

Rate limits are tiered, and they are per model.

• Start · Monthly spend cap: $500 · RPM (Opus 5 / Sonnet 5): 1,000 · ITPM: 2,000,000
• Build · Monthly spend cap: $1,000 · RPM (Opus 5 / Sonnet 5): 5,000 · ITPM: 5,000,000
• Scale · Monthly spend cap: $200,000 · RPM (Opus 5 / Sonnet 5): 10,000 · ITPM: 10,000,000

Managed Agents runs a separate pool: 300 RPM on create endpoints, 1,200 RPM on read, list, and stream. All figures verified against Anthropic's rate limits page on 26 August 2026; they change, so check before you plan capacity.

Managed Agents cannot be used under Zero Data Retention or a HIPAA BAA. Sessions store conversation history, sandbox state, and outputs server-side, which is the point of them and also why they sit outside that coverage. You can delete sessions and files through the API, but if your compliance posture requires ZDR, the Messages API with your own state store is the path.

One more figure worth holding onto: cached reads bill at 10% of base input price, and for most models they don't count toward ITPM at all. Anthropic built that discount because re-sending the same context is the dominant cost in agent workloads. Caching makes re-reading cheaper. It does not make re-reasoning go away.

A worked example: the contract-triage agent

The clearest way to see where the model belongs is to build something with a hard escalation path. Here is the shape of a contract-triage agent, step by step.

What it does

Inbound agreements land in a shared mailbox. The agent reads each one in full, extracts the terms that matter (counterparty, term length, renewal date, notice window, liability cap, anything non-standard), compares them against the organization's standard positions, and routes the result. Clean contracts get recorded and filed silently. Deviations post to Slack with the clause quoted and a link to the record.

How the steps wire together

1. New document arrives in the Gmail or Drive intake folder and fires the trigger.
2. The app uploads it via POST /v1/files and marks the document body as a cache breakpoint.
3. A POST /v1/messages call with an extract_terms tool returns the structured fields.
4. The extraction is validated against the standard-positions table held in the app's database. This step is code, not a prompt.
5. Clean records are written to the database and the contract is filed.
6. Deviations trigger a second Claude call that judges whether the variance is material, then post to Slack for the contract owner.
7. A daily scheduled sweep re-reads the table for renewal notice windows coming due and surfaces them before the deadline passes.

Step 7 is the one a chat session cannot do. A conversation cannot notice that a 60-day notice window opens next Thursday, because it ended in March.

What governance the agent needs

Read-only on the mailbox and the drive folder. Write access scoped to its own records and nothing else. No authority to sign, to send externally, or to edit the standard-positions table, because changing the definition of "standard" is a person's decision. Every action attributed and logged.

This is the shape of control at the point of action: permissions applied where the agent acts, rather than described in a system prompt where they are a suggestion. Database writes should go through a constrained interface for the same reason a guarded database agent does. If you haven't worked through the threat model for agents, a document-ingesting agent with write access is a good place to start.

Build this in Major

Look at what's actually in that seven-step flow. The extraction schema is fixed. The validation rules are a table lookup. The record writes, the Slack routing, the renewal sweep: all of it runs the same way every time. Only two steps need judgment. Reading the document, and deciding whether a clause is genuinely non-standard or just worded oddly. Claude should do those two. The rest should be code.

That is what Major does with a workflow like this. The agent works out the pattern once, builds an app for the repeatable parts, then runs the app instead of re-prompting through the same seven steps every morning. The app carries its own managed database, so the contract records and the standard-positions table live somewhere durable rather than in a context window. Permissions and audit apply at the platform layer, so read-only-on-the-mailbox is enforced rather than requested. And the app is the control surface the contract owner works the queue through, the same artifact the agent writes to. Reason once, run forever.

Prompt caching gets you a 90% discount on re-reading the contract you already read. Not reading it again costs nothing. If you're running the Messages API loop yourself you can build toward this structure by hand, and plenty of teams should. If you'd rather the agent build and govern that app, Major is where that happens.

Start with the triage agent, because it has a clean escalation path and the failure mode is a Slack message rather than a signed contract. Get started on Major and build your contract-triage agent.

Related articles

• Claude Agent: What It Is and How to Build One That Lasts
• Jira Automation for Engineering-Ops AI Agents
• Natural Language to SQL: Building a Guarded Postgres Agent