What is an AI agent?

An AI agent is a language model that chooses its own next step, calls a tool to take it, and repeats until done. A chatbot answers once, from what it was given. A workflow calls a model at fixed points in code a person wrote. An agent decides the path itself, one step at a time.

The tools are what make an agent useful, and what make it risky. A tool can search tickets, read a part record or update a work order. Whatever its tools can reach, the agent can reach.

Every agent runs the same loop. The model reads the task and plans a step. It writes a tool call: a tool’s name and its arguments, in a format the runtime understands. The runtime runs the call and hands the result back. The model reads it, then plans the next step or writes the answer.

Anthropic’s guide Building effective agents describes agents as models using tools in a loop, guided by what each step returns. IBM calls the same pattern a think, act, observe loop, after the ReAct method.

The loop also needs a way to stop. A run ends when the model answers, or when it hits a cap: a number of turns, or a time limit. Our documentation suggests capping an agent at about 8 turns, because an agent with no cap can loop on an ambiguous task.

Not every system that calls a model in steps is an agent. Anthropic’s guide draws the line this way. Workflows “are systems where LLMs and tools are orchestrated through predefined code paths.” Agents “are systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks.”

The difference matters in an enterprise. A workflow takes the same steps every time, so it is easy to test and to audit. An agent can handle a question nobody scripted, at the cost of steps you cannot predict. The guide recommends the simplest thing that works, and a workflow when the task is well defined.

Many useful systems mix the two. A fixed workflow can hand one open question to an agent, and an agent can call a workflow as one of its tools.

A demo agent runs with whatever access its developer gave it. An enterprise agent works on tickets, contracts and maintenance logs that not everyone may read. Four things decide whether it should go near them.

• Tools that run as the person. Every search and every read runs with the access of the person the agent works for, not with a service account that sees everything. NVIDIA’s glossary describes agents that “also check what data and tools they are permitted to access.”
• A scoped reach. Only the tools the task needs. Each tool is one more way for an instruction hidden in a document to reach something.
• A record of every run. The prompts, and each tool call with its arguments and its result. A wrong answer is then something you can read rather than guess at.
• Approval for changes. Reading can run on its own. A tool that changes a record or a configuration stages the change, and a person approves it.

• A service account. The agent runs under one broad account. Anyone who can talk to it can now read what that account reads.
• Too many tools. Tools that overlap leave the model unsure which one to call. Our documentation suggests fewer than about 10 per agent.
• No stopping condition. An ambiguous task loops, and every turn is another model call. Anthropic warns that an agent’s autonomy brings higher costs and errors that compound.
• Instructions in the data. A ticket or a file can carry text that reads like an order. An agent that reads it and can also write somewhere has a path from one to the other.
• No trace. An answer with no record of the tool calls behind it cannot be checked, and a bad one cannot be explained.

Six questions work for any agent, bought or built:

• Would a workflow do? If the steps are known, script them.
• Whose access does each tool run with, and is it checked per record?
• Which tools can change something, and who approves the change before it applies?
• What stops a run: a turn cap, a time limit or a person?
• Can you read a finished run, with every tool call, its arguments and its result?
• Does the answer cite the records it came from?

An agent that runs code needs one more answer: where does that code run, and what can it touch? That is the job of an agent sandbox.

In Curiosity Studio, an agent is a saved configuration: a system prompt, a set of tools and a chat model. The model is a setting: any of 19 built in providers, or one you run yourself. An endpoint, an AI tool or a scheduled task can call the agent.

The built in tools search and read as the person who asked. The read tool rejects a record that person cannot open before any of your code runs. Your own tools get both an unrestricted query and one scoped to the current user. Use the scoped one, and limit who may call a tool with its access groups. An agent writes back only through tools you register, and what they permit is your decision.

Each run is stored as a record: its status, its result and the full transcript of prompts and tool calls. A run times out after 5 minutes by default. Changes to the configuration itself go through Sudo, the admin assistant. He stages each one as a diff in his sandbox and waits for a person to approve it. The AI agents page has the developer view.