AI Agents

From answering questions to doing useful work.

An AI agent earns its place when a task needs software to choose its own next step: look something up, notice what is missing, call a system and prepare an action. ColdAI designs single agents with a narrow role, tools scoped to that role, explicit approval points and a loop that checks every outcome. This page covers how to specify such an agent, when not to build one and how agents fail in production.

Discuss your project Explore the approach

From architecture to integration to operation

The opportunity

Start with a decision
worth improving.

A customer request arrives with missing details. An agent gathers context, prepares the next action and asks for approval before changing an important record.

From possibility to a working system

Follow the flow.

Three connected decisions. One considered architecture.

Conceptual flow, not a live system or measured result.

Define the job

Specify inputs, completion criteria and actions the agent may take. A narrow role with clear exceptions is easier to evaluate and operate than a general instruction to run a department.

RequestRolePolicyContext

Connect the tools

Integrate the agent with the systems required for its task. Scope credentials, validate tool arguments and make irreversible or sensitive actions explicit approval points.

CRMDocumentsToolsApproval

Close the loop

Observe each action and check its outcome. Store useful task state, escalate uncertainty and evaluate the whole workflow, including retries, errors and human intervention.

ActionReceiptReviewNext step

The work, made concrete

What we can build
with your team.

We agree scope, dependencies and acceptance criteria before delivery. Your project can start with an assessment, a pilot or an integration into an existing system.

Agent role and permission design

Clarify the system boundary, the responsible owners and the decisions the architecture needs to support.

Tool integrations and task evaluations

Turn the agreed design into reviewable work, evaluated against representative inputs and explicit success criteria.

Escalation, tracing and operating controls

Make the next step operable: document responsibilities, known limitations and the path from pilot to ongoing use.

In depth

Go deeper into agent design

Method pages for the two questions reviewers ask most often: when must a person approve, and how is a tool-using agent secured?

Assistant, workflow or agent: the terms that set the scope

Teams often argue about tools when they actually disagree about which of these they are building.

Assistant: Answers questions or drafts content for a person, who then decides and acts. It may retrieve documents, but it does not change systems on its own.
Deterministic workflow: A fixed sequence of steps triggered by an event, such as copying a web form into a record. A model call inside it fills one step; it never chooses the route.
Agent: Software that pursues a defined goal by choosing its next step, calling tools and checking results until a completion condition is met or it hands over to a person.
Tool: A function the agent may call, such as a CRM lookup or a draft-email action, with a typed argument schema and permissions of its own.
Completion criteria: The observable conditions that mean a task is finished, written before the agent is built so that success can be tested rather than asserted.
Escalation: A defined handover to a person when the agent lacks information, confidence or permission, including exactly what it passes along.

When a single agent is the right design, and when it is not

If
Every run follows the same steps and the inputs arrive in a structured form
Then
Build a deterministic workflow instead; see n8n and Zapier workflows.
A fixed route is cheaper to run and simpler to audit than a model choosing between routes.
If
People mainly need answers from documents and will act on them themselves
Then
An assistant with retrieval is enough. Add tools later, only for a repeated action that is clearly worth automating.
Every tool an assistant gains widens what can go wrong and what has to be secured.
If
The next step depends on what the system finds, and finishing the task means calling more than one system
Then
This is the case for a single bounded agent with a narrow role.
The value comes from handling variation that a fixed workflow cannot express.
If
The work splits into specialist parts that can run in parallel and need independent checking
Then
Weigh a multi-agent design against a single-agent baseline using our single agent vs multi-agent comparison.
Coordination adds cost and correlated errors, so a team of agents has to beat one agent on evidence.
If
Your users and data already sit inside a Salesforce, Microsoft or AWS environment
Then
Design the role, tools and approval points first, then choose a platform practice such as Salesforce Agentforce, Azure Copilot or AWS Bedrock.
The specification rarely depends on the platform, while the platform choice depends heavily on where the data sits.

Writing the agent specification before the prompt

A specification forces the decisions a prompt tends to hide. The right-hand column fills it in for a hypothetical service-request agent at a property management company.

Element	What to decide	Hypothetical service-request agent
Role	One sentence naming the job and, just as importantly, what is out of scope	Turn tenant maintenance requests into complete, correctly routed work orders; never promise dates or discuss rent
Inputs	Which channels and fields arrive, and what a malformed input looks like	Emails and portal messages, with photos where provided; a request with no matching property goes straight to a person
Tools	Each system call, its argument schema and whether it reads or writes	Property lookup and work-order history (read); create draft work order (write to draft); message tenant (write, approval required)
Approval points	Which actions wait for a person, and what evidence that person sees	Every message to a tenant and any order marked urgent; the coordinator sees the request, the matched property and the proposed order
Completion criteria	The observable state that ends the task	A work order exists with property, category, priority and access notes completed, or the request has been escalated with a reason
Limits	Caps on steps, tool calls, elapsed time and spend per task	A small fixed allowance of tool calls and a time limit, after which the agent stops and escalates
Escalation	The triggers, and what the handover contains	Missing access details, a safety concern or conflicting records; the handover carries everything gathered so far
Success measure	How the whole workflow is judged, not a single answer	Requests completed without correction, time to a routable order and the reason behind each human edit

The same specification feeds the agent's evaluation cases and the review in our AI agent security checklist.

The closed loop behind every agent task

Receive the request
Validate the input and confirm it falls inside the agent's role.
Gather context
Read only the records the role needs, under a scoped identity.
Propose the next action
Choose a tool call or a draft, together with the evidence that supports it.
Approve or proceed
Sensitive actions wait for a person; low-risk ones continue within set limits.
Act through a tool
Execute with validated arguments and capture the target system's response.
Verify the outcome
Compare the receipt with what was intended, then finish, retry or escalate.
Record and learn
Store task state, the trace and any human correction for later evaluation.

Conceptual loop for a single agent task. A real run may pass through gathering and proposing several times before it finishes or escalates.

How single agents fail in production

Loops and runaway retries

Early signalThe same tool is called again and again with small variations, and cost per task climbs.

MitigationSet hard caps on steps, calls and time per task, and treat reaching a cap as an escalation rather than a silent failure.

Malformed or overreaching tool calls

Early signalWrites with missing fields, the wrong record or values outside policy.

MitigationValidate every argument against a schema and business rules in code, outside the model, before the call runs. OWASP lists the broader pattern of agents holding more capability than they need as excessive agency².

Acting on stale or partial context

Early signalProposals contradict what a person can see in the source system.

MitigationRe-read critical records immediately before any write, and show their timestamps to the approver.

Claiming success without finishing

Early signalThe agent reports a task as done, but the target system shows no change.

MitigationConfirm outcomes from the system's own response or a follow-up read, never from the model's summary of what it did.

Reviewer fatigue

Early signalApprovals become instant and edits stop, even as volume grows.

MitigationTier actions by risk so people review only what matters; our human-in-the-loop guide sets out the method.

Evaluating an agent on whole tasks, not single answers

An agent can make a sensible choice at every step and still fail the task: it may pick the wrong record, stop one action short or escalate a case it could have finished. Evaluation therefore scores complete runs against the completion criteria in the specification, including the tool calls made, the approvals requested and the final state of the target system.

Useful measures include tasks finished without human correction, the reasons behind each correction, steps and tool calls per task, cost per completed task and how often an escalation turns out to have been necessary. Set these against how the same work is done today, so the pilot answers a business question rather than a technical one. Building the test set itself is covered in our guide to LLM evaluation sets.

ColdAI scopes agent work around three deliverables: role and permission design, tool integrations with task evaluations, and escalation, tracing and operating controls¹. A pilot may keep human approval for financial, legal or customer-impacting actions, and autonomy widens only as evaluation and production evidence accumulate.

Frequently asked questions

How is an enterprise AI agent different from a chatbot with plug-ins?

A chatbot with plug-ins responds to each message and may call a tool when asked. An enterprise agent owns a task: it decides which steps are needed, calls tools to complete them, checks the results and either finishes or escalates. That ownership is why it needs a written role, scoped permissions, limits and approval points that a chatbot can usually do without.

Which tasks make a good first AI agent?

Recurring tasks with a clear owner, inputs that vary in ways a fixed workflow cannot handle, API access to the systems involved and examples of both good and failed outcomes. Requests that require gathering details from a few systems before a routine update are common starting points, as in our customer support triage use case.

Should an agent act with the requester's permissions or its own?

It depends on the action. Reads on behalf of a user should usually run with that user's permissions, so the agent cannot reveal anything the user could not see. Writes often run under a dedicated agent identity with narrowly scoped rights, which makes its actions easy to trace and revoke. Shared administrator credentials should not be used in either case.

Can an AI agent run without any human approval?

For low-risk, reversible actions with a good track record, yes. Irreversible, financial, legal or customer-facing actions usually start with approval before execution and move to review after the fact only when evidence shows errors are rare and minor. The decision is made per action type, not once for the agent as a whole.

Which platform should we build an AI agent on?

Design the role, tools and approval points first, because they rarely depend on the platform. Then choose based on where your data and users already are, the controls your security team requires and the operating cost. Our platform pages cover options including Salesforce Agentforce, Microsoft Copilot and Amazon Bedrock.

Sources

AI Agents technology practice: deliverables, readiness and boundaries — ColdAI
OWASP Top 10 for LLM Applications 2025 (LLM06:2025 Excessive Agency) — OWASP GenAI Security Project

Connect the architecture

Go deeper into the stack.

Explore the complementary capabilities that can turn an individual technology into a complete workflow.

Strategy & architecture Custom development Ongoing operations Technical reference

Your next move

Bring us the
real problem.

A workflow that takes too long. A system that cannot connect. An idea that needs a technical path. Start there, and we can define what to investigate, build and measure.

A workflow with a clear owner
APIs or approved system access
Examples of successful and failed tasks

See how we approach delivery