# Agent and assistant

Two things in Connect use a model, and they are not the same thing. The **engine** starts work because a message arrived: triage, grounding, drafting, deciding — governed by autonomy. The **Connect Assistant** starts work because you asked, in the app, and its rights are deliberately narrower than yours. Who initiates is the whole distinction, and everything else follows from it.

- **Status:** Available
- **Audience:** both
- **In the app:** #/home, #/activity
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/compare/agent-vs-assistant/

## Who starts, who decides, who answers for it

|  | The engine | The Connect Assistant |
|---|---|---|
| Initiated by | An event — mail arrives, a call comes in, a follow-up falls due | A person typing in the app |
| Runs | Continuously, whether or not anyone is signed in | For the length of your question |
| Governed by | Autonomy mode and scope for the channel it is acting on | The permissions of the person using it, narrowed further |
| Sends outbound | Yes, when autonomy allows; otherwise it drafts and holds | Yes, through the same send boundary, on your instruction |
| Accountable to | The decision log, which records the rule that applied | The same log, recorded against you |

The clearest test: close the browser. The engine keeps working. The Assistant does not exist while you are not there.

## The Assistant's rights are narrower than yours

This surprises people who expect a tool to inherit their permissions wholesale. It does not. The Assistant cannot set pricing and cannot clear a do-not-contact entry — two actions a person with the right role can perform themselves. The reason is that both are irreversible in the way that matters: the first is a commercial commitment, the second removes a protection somebody asked for.

Everything else runs through the same domain services a screen uses. The Assistant does not have a private path to the database, which is why an action it takes is subject to the same workspace scoping and the same audit as the equivalent click.

> **Note** There are 66 product tools. The read-only ones answer questions — `find_anything`, `customer_360`, `list_threads`, `recall`, `status`. The writing ones act — `send_email`, `approve_draft`, `create_followup`, `resolve_case`, `remember`, `forget`. Knowing which kind you have asked for is the difference between a question and a change.

## What confusing them causes

**Expecting the Assistant to work overnight** — It answers; it does not watch. Anything that must happen without you is a follow-up, a standing instruction or an autonomy setting — not a message you left in a chat tab.
**Expecting the engine to answer a question** — It works messages. If you want to know something, ask the Assistant; the engine has no question-answering surface.
**Turning autonomy up to make the Assistant faster** — Autonomy governs what the engine may send unasked. It does not loosen anything about the Assistant, whose actions are yours.
**Assuming an Assistant action is unlogged because it was conversational** — Every action lands in the audit trail against the person who asked for it, including the ones it refused.
**Assuming the engine will pick up an instruction you typed in chat** — A durable direction belongs in a standing instruction or memory. A sentence in one Assistant tab governs that tab.

## Using each for what it is

1. Set the engine's behaviour once: autonomy per channel, standing instructions, Knowledge and memory.
   - Result: Work that arrives while nobody is watching is handled under a rule you wrote, not improvised.
2. Use the Assistant for the things a person needs at that moment — what happened with this account, draft this, approve that, book a follow-up, read this file.
   - Result: Each tab keeps its own conversation, record, draft and files, so two lines of work do not contaminate each other.
3. When the Assistant tells you something surprising, check the citation rather than the sentence.
   - Result: The screen context the model is given is checked against the database before it is trusted, and an answer that cannot be grounded is presented as uncertain rather than confident.

## Questions

### Is the Assistant the same model as the engine?

Model choice is a runtime concern handled in one place and is not a property of the product surface. The distinction that matters to you is not which model runs but who initiated the work and which rights apply — those differ regardless of the model.

### Can I make the Assistant act without confirming?

Its writing tools act on your instruction, and the guard rails are the two it cannot cross plus the ordinary autonomy checks on anything outbound. What it will not do is start acting on its own initiative between your messages — that is the engine's role.

### If both can send an email, why does it matter which sent it?

Because the audit answers different questions. An engine send names the autonomy rule that permitted it; an Assistant send names the person who asked. Months later, 'who released this' is the question somebody actually has.

## Related

- [Connect Assistant](https://connectbyjbrh.com/docs/assistant/)
- [What the Assistant may not do](https://connectbyjbrh.com/docs/assistant/assistant-authority/)
- [Comparisons and concepts](https://connectbyjbrh.com/docs/compare/)
- [The four autonomy modes](https://connectbyjbrh.com/docs/autonomy/modes/)
- [Autonomy and approval](https://connectbyjbrh.com/docs/compare/autonomy-vs-approval/)
- [Why only one loop may think](https://connectbyjbrh.com/research/single-thinker/)

## What this page is based on

- `docs-source/sources/GENERAL.md` §8 — the Assistant, its tools and rights
- `docs-source/sources/GENERAL.md` §5 — autonomy and the audit trail
- `docs-source/sources/GENERAL.md` §4 — agent loop modules
- Connect capability registry (docs-source/facts.py)