Web, CLI, IDE, API or messaging: choose an interface

An AI interface shapes model context, tool access, review and failure handling.

Interface is only one design axis. It is distinct from:

• execution location: a user’s device, internal infrastructure or an external service;
• runtime: the software that loads and runs a model;
• harness: the prompts, tools, retrieval, permissions and workflow controls surrounding it.

A browser interface can connect to a self-hosted service. A local API can expose a model running on the same machine. A CLI can call either local or external infrastructure. Choosing an interface does not establish privacy, capability or execution location.

Compare the five interfaces

Interface	Candidate use	Potential advantage to evaluate	What to verify
Web browser	Exploration, drafting and human-reviewed decisions	Accessible conversational review	Attachments, history, export, accessibility and sharing
CLI	File operations, technical workflows and recorded runs	Proximity to files and developer tools	Permitted files, commands, credentials and rollback
IDE	Code explanation, edits and diff review	Relevant code context beside implementation tools	Exactly which editor and repository context is supplied
API	Repeatable application integration	Structured input, validation and retries	Schemas, versions, errors, limits and approval boundaries
Messaging	Authorised access and notifications	Reaches people in an existing channel	Sender identity, retention and downstream permissions

These are selection criteria, not promises that every product offers every listed capability.

Web browser: support human review

A browser can support human-led research, comparison and drafting pilots.

Its convenience can conceal an inconsistent process. Different users may paste different context, omit attachments or leave decisions buried in conversation history. Before depending on browser work, check:

• supported attachment types and limits;
• how history is retained and shared;
• whether useful records can be exported;
• keyboard, screen-reader and other accessibility support;
• who can access a conversation; and
• whether a reviewer can reconstruct the sources and instructions.

CLI: work near files and tools

A command line interface can place AI assistance close to repositories, scripts and local files. Check the chosen product’s actual file, session and model controls; no particular implementation is tested here.

Commands and session records can make a process easier to inspect, but they do not make model output deterministic. Prompts, model versions, environment state and tool configuration can all alter a result.

A CLI suits bounded file or tool work where an implementer can review the changes. Define permitted directories and commands, protect credentials, retain an appropriate run record and provide a way to detect or reverse partial changes. Running locally should not mean granting access to an entire home directory or production environment.

IDE: put code context beside review

An IDE interface can reduce friction for explaining code, making targeted edits and reviewing diffs. Record which selections, files or diagnostics the chosen implementation actually supplies; do not infer this from the label “IDE”.

That context is useful, but it does not prove that a model understands the whole repository. Running a CLI inside an IDE is also not necessarily equivalent to every feature of a native IDE agent.

Verify what the implementation actually supplies: selected text, open tabs, indexed files, diagnostics, repository state or another defined set. Keep ordinary engineering controls—including tests, diff review and authorised deployment—in place. IDE convenience should accelerate review, not replace it.

API: integrate a bounded task

An API becomes useful when a task is stable enough to place inside an application workflow. It can support structured inputs, schema checks, controlled retries and explicit error handling.

API access describes a programmatic interface, not the model’s location. Record the actual endpoint, processing route and operator separately from the interface name.

Nor does compatibility with a familiar API establish feature parity. If an application uses structured output, streaming, tool calls, cancellation or particular error behaviour, test those requirements against the chosen implementation.

Define required fields, accepted outputs, timeouts, retry limits, version controls and escalation routes. A response that passes a schema check can still be wrong and may still need human review.

Messaging: separate identity from authority

Messaging can let approved people contact an assistant or receive notifications through an existing channel. For a named product, check its current identity, access and tool settings separately; use the canonical Hermes guide for product detail.

A gateway connects users, agents, models and tools; it is not itself the model. An authenticated sender is also not automatically authorised to use every tool or view every record. Verify sender identity and downstream data permissions separately.

External messaging platforms have their own retention and data-handling conditions. Decide what information may appear in a message, who may initiate contact and which actions still require approval.

Hypothetical, untested pilot: classify enquiries

Suppose a business wants to classify enquiries as support, sales, billing or unclear.

Begin in an isolated browser pilot. A staff member creates invented enquiries containing no real personal or client information and reviews every proposed category. The aim is to refine the decision rules, not to automate live records.

Next, a bounded API integration could accept approved fields and return a category, short reason and uncertainty indicator. Invalid, sensitive or ambiguous results would enter a human review queue.

Messaging could then notify the responsible person that an item requires review. It would not contact the enquirer or commit a production classification automatically.

Task	Input	Execution boundary	Review owner	Failure path
Refine categories	Invented enquiries	Isolated browser pilot	Service lead	Mark unclear and revise guidance
Produce classification	Approved structured fields	Bounded API workflow	Workflow owner	Reject invalid output and queue review
Notify reviewer	Minimal reference and status	Approved messaging channel	Assigned staff member	Keep item queued and raise an operational alert
Commit result	Human-approved category	Existing business system	Authorised record owner	Make no change without approval

This entire example is fictional and untested. Use synthetic enquiries and isolated test destinations. No account, interface or integration was executed, and no pass result is supplied.

To compare interfaces fairly, keep the underlying model and decision rubric fixed where possible. Record model and version, system instructions, supplied context, available tools and output settings. If an interface changes retrieval, prompts, tools or context, treat that difference as a confound rather than declaring the interface itself more accurate.

Implementer worksheet

Record:

1. Who starts the task, and who reviews it?
2. Which files, attachments or records are necessary?
3. Where does execution occur?
4. What does the harness retrieve, expose or permit?
5. Is the output advice, a draft, a code change, structured data or a notification?
6. Can a reviewer reconstruct the material inputs and configuration?
7. What happens after an invalid response, timeout or unavailable service?
8. Have sender identity and tool permissions both been verified?
9. Are history, export and accessibility adequate for intended users?
10. Which actions still require human approval?

Choose an interface that supplies the required context, control and evidence. Combining interfaces adds permission, context and failure boundaries.

Choose and record the next action

Record the chosen surface, the task and reviewer, required context, allowed operations, unavailable features, evidence gaps and next test. If a required observation is missing, record hold, not “supported”. For an API or messaging notification, distinguish proposed, attempted, confirmed and uncertain effects; reconcile uncertain effects before retrying. Interface convenience is not evidence of reliability.

Use the parent workflow contract to decide whether tools or a dynamic agent are needed. Link the existing C2 authority record for detailed access and refusal checks. Use A2 to verify the intended account’s access, and C5 to record bounded task acceptance and recovery. Coding tests remain in D2 and D3.

Sources and limits

The matrix and enquiry example are original design criteria. Anthropic’s Building effective agents, sections “What are agents?” and “When (and when not) to use agents”, checked 7 October 2026, supplies architectural context; it does not document feature parity among web, CLI, IDE, API and messaging products.

No interface, account or connected workflow was tested. Accessibility, history/export, supported fields, latency, privacy, reliability and portability must be inspected in the chosen implementation. No universal interface winner or equivalent capability is claimed.