# Digital employee A digital employee is software given a standing role in a business rather than a task. It holds responsibilities across channels, keeps a durable record of the people it deals with, works to rules its employer sets, and answers for what it did. The distinguishing feature is not intelligence but continuity: it is the same worker tomorrow, with yesterday's context. - **Status:** Reference - **Audience:** both - **Last verified:** 2026-09-10 - **Canonical:** https://connectbyjbrh.com/docs/technology/digital-employee/ ## Four properties that separate the category from a task agent **A standing role** — It is responsible for a channel or a function continuously, not for one request. Nobody launches it; it is either on or deliberately off. **Durable memory** — What it learns about a person survives the conversation that taught it. A task agent starts from nothing every time. **Explicit authority** — What it may do alone is written down and enforced outside the model. A task agent's authority is whatever its caller happened to grant. **An account of itself** — Every decision has a record naming what was decided, under which rule, with what result — because a business has to answer for what its worker said. Remove any one of the four and the category collapses back into a chatbot with tools. Memory without authority produces a system that knows a great deal and may not act. Authority without a record produces one nobody can defend in a dispute. ## Does Connect use this idea, or is it one? Connect **is** an implementation of this category — it is the product's own description of itself, and the four properties map onto named parts of the system rather than onto adjectives. The role is per channel and per mailbox; the memory is [four tiers](/docs/memory/tiers/) from the workspace down to one person; the authority is [autonomy](/docs/autonomy/), which is ordinary code and database rules that the model never evaluates; the account of itself is the [audit trail](/docs/autonomy/audit-trail/). That is a claim about design, not about quality. A reader deciding whether the category suits their business should read [Current limits](/docs/product/limits/) beside this page, because the honest boundaries of the implementation are more useful than the category's promise. ## Why the distinction changes a buying decision | Question | Task agent | Digital employee | |---|---|---| | Who starts the work? | A person, each time. | An event on a channel, or a schedule. | | What does it remember? | The current conversation. | The relationship, across channels and months. | | Who decides what it may send? | Whoever wrote the calling code. | The business, per channel, in a setting it can change. | | What happens when it is unsure? | It answers anyway or fails. | It reserves the decision and asks a named person. | | What does the business get afterwards? | An output. | A record: what happened, why, what it cost, what is owed. | The practical consequence is the shape of the working day. A task agent adds a tool to somebody's list. A digital employee removes a queue from it and replaces it with a shorter queue of decisions — which is only an improvement if the second queue is genuinely shorter, and that is a question about the [autonomy settings](/docs/autonomy/modes/) rather than about the model. ## The failure mode the category invites > **Careful** A standing role with weak boundaries is worse than no role at all. Software that answers the phone at three in the morning and invents a price has done more damage than software that does not answer. This is why the interesting engineering in the category is not the conversation but the refusal: what happens when Knowledge does not support an answer, when a promise cannot be kept, when a budget is spent, when a provider is down. Those are the pages worth reading before the demonstration — [unsupported claims](/docs/knowledge/unsupported-claims/) and [what Connect will not do](/docs/getting-started/what-connect-will-not-do/). ## Terms this is confused with - **AI agent** — the mechanism, not the employment model. A digital employee is built out of one; see [AI agent](/docs/technology/ai-agent/). - **Assistant** — reactive, scoped to a person's request. Connect has one of those too, and it is a different thing from the engine. - **Workflow automation** — deterministic steps with no judgement. Compare at [Connect vs workflow automation](/docs/compare/connect-vs-workflow-automation/). - **Copilot** — suggests, never acts alone. The distinction is authority, which is the third property above. There is no external standard for this category — it is a market term, not a specification. The nearest neutral reading is the academic literature on autonomous agents; for the mechanism underneath, the specification worth reading is the Model Context Protocol at [modelcontextprotocol.io](https://modelcontextprotocol.io/specification/2026-07-28), because it is where tool authority is being standardised. ## Questions ### Is 'digital employee' just marketing for chatbot? It is marketing when the four properties are missing, which is often. The test is not what the vendor calls it but whether you can point at where the memory lives, where the authority is enforced, and where the record of a decision is written. ### Does a digital employee replace a person? It takes the queue, not the judgement. In Connect the reserved decisions — prices, exceptions, anything the rules mark — are routed to a person through Needs You rather than answered. ### Can I turn it off? In Connect, yes, immediately and per channel, without losing any settings. That switch is part of the category: a standing role that cannot be stood down is a liability. ## Related - [Digital employee and AI agent](https://connectbyjbrh.com/docs/compare/digital-employee-vs-ai-agent/) - [Digital employee](https://connectbyjbrh.com/docs/glossary/digital-employee/) - [AI agent](https://connectbyjbrh.com/docs/technology/ai-agent/) - [Connect by JBRH](https://connectbyjbrh.com/docs/product/) - [The four autonomy modes](https://connectbyjbrh.com/docs/autonomy/modes/) ## What this page is based on - Connect capability registry (docs-source/facts.py) — CANONICAL_TERMS - AGENTS.md §8 — boundaries and the two audiences - Model Context Protocol specification (https://modelcontextprotocol.io/specification/2026-07-28)