Custom AI Assistant vs Agent: A Practical Taxonomy

Saved Prompt, Custom Assistant, Workflow, or Agent?

A saved prompt is not automatically an assistant, and a custom assistant is not automatically an agent. The useful classification depends on what persists, what the system can access, what it can do, who starts the work, and where human approval occurs.

The product name is secondary. Two interfaces can produce similar text while carrying completely different authority.

flowchart LR
    A["Reusable text"] --> B["Saved prompt"]
    B --> C["Persistent instructions and context"]
    C --> D["Custom assistant"]
    D --> E["Defined sequence"]
    E --> F["Workflow"]
    F --> G["Tools and permissions"]
    G --> H["Tool-using workflow"]
    H --> I["System selects and revises steps"]
    I --> J["Agentic loop"]

Start with the system boundary

Imagine four systems that can draft the same weekly report.

The first stores a prompt that a person pastes into chat. The second keeps the instructions and approved reference files in a named assistant. The third runs a fixed sequence that imports a report, calculates values, drafts commentary, and pauses for review. The fourth can inspect an inbox, decide which files to gather, retry a failed step, and send the report.

The text output might look similar. The failure modes are not.

The first can generate a bad draft. The fourth can touch external systems, expose data, repeat an action, or communicate without the right approval. Calling all four "agents" removes the detail needed to design and govern them.

A saved prompt stores reusable language

A saved prompt is text that can be invoked again. It may describe a role, task, process, tone, format, or set of rules. The user still decides when and where to use it.

Saving a prompt does not add a private knowledge base, memory across sessions, external tools, or permission to act. It is closer to a reusable form than a worker.

Saved prompts are useful when the task is portable and the user wants to see the full instruction each time. They are also easy to version and compare.

A custom assistant adds persistent configuration

A custom assistant combines a model with persistent instructions. It may also include approved sources, examples, starters, a name, and a visual identity.

Google's current Gem documentation describes persistent instructions, optional knowledge files, previews, and reuse across chats. Meta's AI Studio launch record describes custom characters and creator AIs with social distribution.

Those are product examples, not definitions. A custom assistant may still be entirely reactive. The user asks; the system answers.

E033's Curio and Venture Episode Engine are best understood this way. They stored instructions and generated responses. They did not demonstrate independent initiation or broad execution authority.

A source-grounded assistant constrains evidence

Some assistants are configured around an approved source set. They retrieve from that material and may expose citations or passages for review.

The key questions are whether the corpus is complete, how retrieval selects passages, whether the answer stays within the source boundary, and whether a reader can inspect support. A source-grounded system can still miss a passage, misunderstand a conflict, or cite material that does not support the claim.

This is why [[Source-Grounded AI or General Chat]] and [[How to Verify an AI Answer Against Its Citations]] treat grounding as an evidence path rather than an accuracy guarantee.

A workflow connects defined steps

A workflow turns work into a sequence. Some steps may be ordinary code and others may call a model.

A simple content workflow might validate the source, extract claims, draft a page, run style checks, and route the result for human review. The steps and transitions are designed in advance.

This distinction matters because a workflow can be highly automated without being broadly autonomous. Deterministic steps may be easier to test, repeat, and recover than a model deciding everything.

A tool-using workflow can affect another system

When the system can search a private drive, query a database, create a ticket, edit a file, or send a message, tools and permissions enter the boundary.

Now the design needs credentials, least privilege, write scope, approval, logging, duplicate protection, timeouts, and recovery. "Can call email" is not enough. The description should say whether it can read, draft, send, delete, or change labels, and under whose account.

The authority belongs in the name of the design, even when the interface still looks like chat.

An agentic loop selects and revises steps

An agentic system can choose actions toward a goal, observe the result, and revise the next step within a defined loop. It may plan, call tools, recover from some errors, and continue without a new prompt for every transition.

That does not mean unlimited autonomy. A useful agent may operate inside a narrow budget, tool set, data boundary, and time window while stopping for approval before any consequential write.

Autonomy is a degree. A system can be agentic in planning but not authorized to send. It can act on a test environment but not production. It can propose a change but not approve it.

A public persona is a separate risk dimension

A public AI character may be technically simpler than a private workflow. It can still be harder to govern because strangers interact with it and may treat its identity as meaningful.

A public persona needs disclosure, consent, moderation, abuse handling, support, deletion, and a shutdown path. If it represents a creator or company, it also needs rules for what counts as an authorized statement.

Audience is therefore not just a sharing setting. It changes the system category from a governance perspective.

Use a capability and authority record

This matrix is more informative than debating whether a system feels agentic.

A plain-language naming rule

Name the lowest-complexity category that accurately describes the system, then add the important capabilities.

"A custom assistant with persistent instructions and three approved source files" is clearer than "research agent." "A scheduled workflow that drafts a report from an authorized export and waits for approval" is clearer than "operations agent." "A tool-using loop that can update test tickets but cannot close them" is clearer than "autonomous engineering agent."

No single taxonomy is universal. This one is designed to make architecture, risk, and ownership visible.

NIST's Generative AI Profile emphasizes that risk varies by lifecycle stage, system level, use case, actors, and consequences. Precise system descriptions make that analysis possible.

Use [[How to Design a Reusable AI Assistant]] when persistent instructions are enough. Use [[How to Test an AI Assistant on a Bounded Task]] before expanding the scope. Use [[Private Productivity Assistant or Public AI Persona]] when the audience itself changes.

This explainer was developed with AI assistance from E033, current product records, the linked operational taxonomy, and NIST guidance. Dalton Anderson remains the author. Editorial, technical, privacy, security, safety, current-source, and founder review are mandatory before publication. Publication is not authorized.