# AI agent

An AI agent is a loop: it observes something, decides what to do, calls a tool that changes the world, observes the result, and goes round again until it is finished or stopped. The model supplies the decision. Everything that makes the loop safe — what it may call, when it must stop, what it is allowed to believe — is ordinary software around it.

- **Status:** Reference
- **Audience:** both, developer
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/technology/ai-agent/

## The loop, drawn small

```text
observe   →  a mail arrives / a caller speaks / a follow-up falls due
   ↓
ground    →  what does the business already know that bears on this?
   ↓
decide    →  the model proposes: an answer, a tool call, or "I cannot"
   ↓
permit    →  code checks the proposal against rules. Not the model.
   ↓
act       →  the tool runs; the provider answers; evidence is stored
   ↓
record    →  relationship, timeline, audit, usage
   ↓
observe   →  the result is the next observation
```

Two of those six boxes are the model's. The other four are code, and the quality of an agent in a business setting is decided almost entirely by them. An agent whose *permit* step is a sentence in the prompt asking it to be careful has no permit step.

## Three things that make one useful at work

1. **Tools that do real things with real credentials.** An agent that can only talk is a search box with a better manner. The interesting risk and the interesting value both start at the first side effect.
2. **Grounding in the employer's own material.** A general model knows the world; it does not know your delivery times. Answers that cannot be traced to something the business supplied are the largest single source of expensive mistakes.
3. **A stopping rule the model does not own.** Budgets, allowances, approval gates and refusals belong outside the loop, or the loop decides its own limits — which is the same as having none.

## Does Connect use an agent loop?

**Used**, and in two distinct places with different shapes. The background engine (`agent.py`, `runner.py`) runs the loop above over mail, calls, follow-ups and prospecting: triage, ground, draft, decide. The in-app [Connect Assistant](/docs/assistant/) runs a shorter, person-initiated loop with a tool set of its own — 66 tools at the last count, each with a schema and its own permission check.

On a live phone call the loop is compressed into the model session itself: a speech-to-speech model listens and speaks continuously and calls Connect's tools mid-sentence. The permit step still sits outside it — every spoken sentence is posted back and re-checked against the guardrails after the fact, and an escalation phrase queues a transfer rather than the model performing one.

> **Note** The model never evaluates whether an action is permitted. That is [autonomy](/docs/autonomy/), which is code and database rules, and it is the reason a prompt-injection attempt in an incoming mail cannot grant itself the right to send.

## The two properties that make an agent dangerous

| Property | Why it is dangerous | What contains it here |
|---|---|---|
| Autonomy over side effects | A mistake is not a wrong answer on a screen; it is a message somebody received. | Per-channel autonomy modes, held drafts, and an approval queue. |
| Untrusted input in the same channel as instructions | Anything the agent reads can try to instruct it. | Instructions and content are separated; content never grants authority. See [prompt injection](/docs/technology/prompt-injection/). |

Both are structural rather than model-dependent. A better model reduces the rate of bad proposals; it does not change what a bad proposal is allowed to do.

## Where the field is being written down

There is no single standard for what an agent is. Two specifications matter because they standardise the edges: the [Model Context Protocol](https://modelcontextprotocol.io/specification/2026-07-28) for how an agent reaches tools and data, and the [A2A protocol](https://a2a-protocol.org/latest/specification/) for how one agent addresses another. Connect publishes surfaces for both — see [Protocols](/docs/protocols/).

## Questions

### Is an AI agent the same as a large language model?

No. The model is one component — the decision step. An agent is the loop, the tools, the permissions and the record around it. Swapping the model changes quality and cost; it does not change what the agent is allowed to do.

### How many steps should an agent take on its own?

As many as it can take without a side effect, and then it should stop at the first one that leaves the system — which is where a permission check belongs. Long autonomous chains of reads are cheap; long autonomous chains of writes are how a small error becomes a large one.

### Does the agent learn from what happens?

In Connect, it records rather than retrains. Durable facts go into Memory, corrections supersede earlier entries, and no customer data trains a model.

## Related

- [Agentic workflow](https://connectbyjbrh.com/docs/technology/agentic-workflow/)
- [Tool calling](https://connectbyjbrh.com/docs/technology/tool-calling/)
- [Agent and assistant](https://connectbyjbrh.com/docs/compare/agent-vs-assistant/)
- [How Connect works](https://connectbyjbrh.com/docs/product/how-connect-works/)
- [Prompt injection](https://connectbyjbrh.com/docs/technology/prompt-injection/)

## What this page is based on

- AGENTS.md §2 — the agent loop (`agent.py`, `runner.py`, `manager_tools.py`)
- Connect capability registry (docs-source/facts.py) — assistant_tools, autonomy_modes
- Model Context Protocol specification (https://modelcontextprotocol.io/specification/2026-07-28)