A chat is an agent with a human inside the loop
I've been trying to figure out where AI agents actually fit in my life. Not in a "agents will change everything" way — in a practical one. I run a small personal automation platform (expenses, emails, career stuff, telemetry), and I recently added the ability to run agents in ephemeral containers: give a prompt, the agent works in a loop, and what comes back is a progress log, a final answer, and artifacts — files it produced along the way. And then it hit me: my chat assistant does tool-ish things too. So what's actually the difference? <!-- excerpt --> ## The mechanics are the same Technically, a chat and an agent are the same thing: a loop of **model → tool call → result → model → …** until there's a final answer. The chat you use every day already has search, code execution, even a hidden filesystem in its sandbox. So "agentness" is not a property of the model. It's a property of the **harness** around it. Three things actually differ: **Who holds the loop.** In a chat, the loop is short and anchored to you — the model does a couple of tool calls and comes back, because you're sitting there waiting. _You_ are the planner: read, clarify, next step. An agent holds the loop itself — dozens of turns, no human in between. **The environment.** A chat gets generic tools: search, a sandbox, maybe a few connectors. An agent runs in an environment _you_ built: a workspace that survives as artifacts, access to your own APIs, whatever CLIs you baked into the image. A chat can't query my expenses. My container can. **Synchronicity.** A chat is "I sit and wait for the answer." An agent is "I fire a task, walk away, get a push notification." That changes the class of viable tasks: a 20-minute job is a terrible chat experience and a perfectly fine background job. So: **a chat is an agent with a human planner inside the loop, running in someone else's environment.** ## Where agents actually pay off The honest realization: a bare agent — a prompt going into a container with no access to anything — is just "Claude in a box, without internet." It loses to a chat, which at least has search and a nice UI. The value appears at the intersection of two things: the agent has access to **your data and tools**, and the task has an **unknown number of steps**. That gives a simple filter for every idea: _would cron plus a single LLM call be enough?_ If yes — you don't need an agent. Three categories survive that filter for me: 1. **Recurring review with judgment.** Weekly pass over expenses: "here are three anomalies and why." Not threshold rules — interpretation. The agent can dig further, fetch context, compare with last month. 2. **A watchdog with a brain.** Classic monitoring is thresholds, and thresholds don't need an agent. What needs one is _diagnosis_: "look at yesterday's request telemetry, is anything weird, and if so — dig in and tell me what changed." The output is not an alert; it's a small report with a conclusion. 3. **Delegation from the phone.** Fire a task while walking, agent grinds for ten minutes, push notification, open the app, read the answer and the artifacts. ## The chat becomes a dispatcher If a chat and an agent are the same loop with different harnesses, they compose naturally: the chat is the **face**, agents are the **hands**. The chat talks to the human, answers fast questions directly, and for anything long it has a tool: _launch an agent_. Crucially, it also has tools to _read the results back_ — so the loop closes: "check why the backend was slow yesterday" → the chat expands my two words into a proper task brief (this alone kills the pain of writing long prompts on a phone) → agent job → push → "so, what did it find?" → the chat reads the job output and summarizes it. A dispatcher and a secretary in one. ## Two kinds of tools Building this, I noticed the tools split cleanly into two types, and they need different plumbing: - **"Do it for the user"** — generate an image, launch an agent. The model fills in an action, the backend executes it, and the model never needs to see the result. A single pass is enough; the result is for the human, not the model. - **"Find out for me"** — query data, read a job's output. Here the model _must_ see the result before it can answer. This is the real tool loop: call, observe, maybe call again, then answer knowing the facts. A dispatcher without the second type is deaf: it can give orders but can't read the reports. And the budgets differ too. Chat tools must be **few, fast, and curated** — a human is waiting, and dispatch quality degrades when tools are many and poorly distinguishable. Agent tools can be **many and slow** — nobody's waiting. The same data access can exist in both forms: narrow fast queries in the chat, "crawl as long as you need" in the agent. Side note on MCP: for your _own_ platform you don't need it at all — your tools are just functions over your own API. MCP earns its keep for **third-party** services, and those plug more naturally into the agent side of the split than into a lightweight chat. ## What I took away - Agentness lives in the harness, not the model. A chat is already an agent — with you as the planner. - A bare agent loses to a chat. An agent with _your_ environment wins where a chat physically can't go. - The filter for every idea: if cron + one LLM call is enough, it's not an agent task. - Chat as dispatcher, agents as workers, and result-reading tools to close the loop — that's the architecture worth building. - Actions can be fire-and-forget; questions need a real tool loop. None of this is novel — it's roughly how modern coding agents orchestrate their subagents. But re-deriving it from my own use cases is what made it stick.I’ve been trying to figure out where AI agents actually fit in my life. Not in a “agents will change everything” way — in a practical one. I run a small personal automation platform (expenses, emails, career stuff, telemetry), and I recently added the ability to run agents in ephemeral containers: give a prompt, the agent works in a loop, and what comes back is a progress log, a final answer, and artifacts — files it produced along the way.
And then it hit me: my chat assistant does tool-ish things too. So what’s actually the difference?
The mechanics are the same
Technically, a chat and an agent are the same thing: a loop of model → tool call → result → model → … until there’s a final answer. The chat you use every day already has search, code execution, even a hidden filesystem in its sandbox.
So “agentness” is not a property of the model. It’s a property of the harness around it. Three things actually differ:
Who holds the loop. In a chat, the loop is short and anchored to you — the model does a couple of tool calls and comes back, because you’re sitting there waiting. You are the planner: read, clarify, next step. An agent holds the loop itself — dozens of turns, no human in between.
The environment. A chat gets generic tools: search, a sandbox, maybe a few connectors. An agent runs in an environment you built: a workspace that survives as artifacts, access to your own APIs, whatever CLIs you baked into the image. A chat can’t query my expenses. My container can.
Synchronicity. A chat is “I sit and wait for the answer.” An agent is “I fire a task, walk away, get a push notification.” That changes the class of viable tasks: a 20-minute job is a terrible chat experience and a perfectly fine background job.
So: a chat is an agent with a human planner inside the loop, running in someone else’s environment.
Where agents actually pay off
The honest realization: a bare agent — a prompt going into a container with no access to anything — is just “Claude in a box, without internet.” It loses to a chat, which at least has search and a nice UI.
The value appears at the intersection of two things: the agent has access to your data and tools, and the task has an unknown number of steps. That gives a simple filter for every idea: would cron plus a single LLM call be enough? If yes — you don’t need an agent.
Three categories survive that filter for me:
- Recurring review with judgment. Weekly pass over expenses: “here are three anomalies and why.” Not threshold rules — interpretation. The agent can dig further, fetch context, compare with last month.
- A watchdog with a brain. Classic monitoring is thresholds, and thresholds don’t need an agent. What needs one is diagnosis: “look at yesterday’s request telemetry, is anything weird, and if so — dig in and tell me what changed.” The output is not an alert; it’s a small report with a conclusion.
- Delegation from the phone. Fire a task while walking, agent grinds for ten minutes, push notification, open the app, read the answer and the artifacts.
The chat becomes a dispatcher
If a chat and an agent are the same loop with different harnesses, they compose naturally: the chat is the face, agents are the hands.
The chat talks to the human, answers fast questions directly, and for anything long it has a tool: launch an agent. Crucially, it also has tools to read the results back — so the loop closes: “check why the backend was slow yesterday” → the chat expands my two words into a proper task brief (this alone kills the pain of writing long prompts on a phone) → agent job → push → “so, what did it find?” → the chat reads the job output and summarizes it.
A dispatcher and a secretary in one.
Two kinds of tools
Building this, I noticed the tools split cleanly into two types, and they need different plumbing:
- “Do it for the user” — generate an image, launch an agent. The model fills in an action, the backend executes it, and the model never needs to see the result. A single pass is enough; the result is for the human, not the model.
- “Find out for me” — query data, read a job’s output. Here the model must see the result before it can answer. This is the real tool loop: call, observe, maybe call again, then answer knowing the facts.
A dispatcher without the second type is deaf: it can give orders but can’t read the reports.
And the budgets differ too. Chat tools must be few, fast, and curated — a human is waiting, and dispatch quality degrades when tools are many and poorly distinguishable. Agent tools can be many and slow — nobody’s waiting. The same data access can exist in both forms: narrow fast queries in the chat, “crawl as long as you need” in the agent.
Side note on MCP: for your own platform you don’t need it at all — your tools are just functions over your own API. MCP earns its keep for third-party services, and those plug more naturally into the agent side of the split than into a lightweight chat.
What I took away
- Agentness lives in the harness, not the model. A chat is already an agent — with you as the planner.
- A bare agent loses to a chat. An agent with your environment wins where a chat physically can’t go.
- The filter for every idea: if cron + one LLM call is enough, it’s not an agent task.
- Chat as dispatcher, agents as workers, and result-reading tools to close the loop — that’s the architecture worth building.
- Actions can be fire-and-forget; questions need a real tool loop.
None of this is novel — it’s roughly how modern coding agents orchestrate their subagents. But re-deriving it from my own use cases is what made it stick.