# Digital employee and AI agent

**AI agent** describes a mechanism: a model given tools, run in a loop until a task is done. **Digital Business Employee** describes an arrangement: one worker that holds a job permanently, remembers the business, follows through on commitments and can be held to account for what it did. Connect is built as the second, using the first. The words are not interchangeable and the difference shows up in what you buy.

- **Status:** Reference
- **Audience:** both
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/compare/digital-employee-vs-ai-agent/

## The mechanism and the arrangement

The agent pattern is a good description of how work gets done inside Connect: a model reads a message, calls tools, and stops when it has produced something. That pattern says nothing at all about whether anything survives the run, whether a second run knows what the first one promised, or who answers for a mistake.

The employee framing is about exactly those questions. It sets three expectations that a mechanism does not.

**Permanence** — The same worker holds the job across every conversation. Memory resolves at four tiers — workspace, channel, endpoint, contact — narrowest first, so what it learned about a customer in March governs a call in September without anyone re-explaining.
**Responsibility** — Commitments are records. A follow-up carries a reason, a due time and a channel, is drained on that channel, and is closed as missed rather than executed a day late.
**Oversight** — There is a stated rule for what it may do without asking, and a log of what was decided, by what, under which rule — including refusals, because a refusal is a decision.

## What goes wrong when the words are swapped

| The mistake | What follows |
|---|---|
| Buying agents per task | Six task-shaped agents, six sets of context, and no record that knows the caller on Thursday is the person who emailed on Monday. The integration bill arrives later |
| Expecting an agent to remember | It remembers within its run. Continuity across runs is a storage design, not a model capability — and if nobody designed it, there is none |
| Expecting an employee to be general-purpose | A Digital Business Employee has a job, a workspace and a set of records. It is not a research tool and does not do work outside the business it works for |
| Assuming accountability comes free | A transcript is not an audit trail. Knowing *what was decided, under which rule, and what happened* is something the system has to record on purpose |
| Assuming a smarter model fixes continuity | It does not. The gap is between runs, and no amount of capability inside one run closes it |

## Where the agent framing is the better one

For engineers, *agent* is the precise word and *employee* is marketing. If you are building — choosing a tool interface, reasoning about loop termination, deciding what a tool may do — the mechanism is what you need to think about, and the employee metaphor obscures it. Connect's own developer surfaces use the technical vocabulary throughout: tools, resources, transports, scopes.

The metaphor also has a limit worth stating: an employee has judgement that survives contact with the unwritten, and Connect deliberately does not improvise where its Knowledge is silent. On a commercial question it refuses and escalates. That is the correct behaviour and it is also the point at which the metaphor stops being accurate.

## How Connect implements the arrangement

- **One canonical record.** Threads, messages, calls, people, companies — the engine reads canonical rows, never a provider's own tables, so what the worker knows does not depend on which mailbox provider you use.
- **One send boundary.** The engine and a person send through the same code, and **sent** requires a provider acknowledgement.
- **One rule for what it may do.** Autonomy per channel, resolved at four scopes with the narrowest winning.
- **One queue for what needs a person.** [Needs You](/docs/autonomy/needs-you/), ranked rather than chronological, draining as causes clear.
- **Memory a person can read and delete**, at every tier.

> **Note** The product category name is **Digital Business Employee**. It is a description of the arrangement above, not a claim that anything on the payroll has been replaced.

## Questions

### Is this just a marketing word for an agent?

It would be if nothing behind it changed. What makes it a real distinction here is that the properties it implies are implemented and checkable: four-tier memory across conversations, commitments with reasons and due times, an autonomy rule, and a decision log that records refusals.

### Can I build the same thing from agents myself?

Yes, and the hard parts will not be the agents. They will be the canonical record that survives every run, identity resolution across channels, the compliance checks before an outbound, and an audit trail somebody can read months later.

### Does a digital employee replace a person?

This documentation makes no such claim. What is describable is the shape of the work: first contact is handled, what cannot be finished is raised with the conversation attached, and a person spends their attention on decisions rather than on triage.

## Related

- [AI agent](https://connectbyjbrh.com/docs/technology/ai-agent/)
- [Digital employee](https://connectbyjbrh.com/docs/technology/digital-employee/)
- [Comparisons and concepts](https://connectbyjbrh.com/docs/compare/)
- [Agent and assistant](https://connectbyjbrh.com/docs/compare/agent-vs-assistant/)
- [The four memory tiers](https://connectbyjbrh.com/docs/memory/tiers/)
- [Digital employee](https://connectbyjbrh.com/docs/glossary/digital-employee/)

## What this page is based on

- `docs-source/facts.py` — CANONICAL_TERMS, Digital Business Employee
- `docs-source/sources/GENERAL.md` §5–§7 — autonomy, memory, follow-ups
- `docs-source/sources/CHANNELS.md` §1 — the canonical mail model
- `docs-source/sources/CHANNELS.md` §6 — refusal on commercial terms