An agent and an editor can be separate products
Agent Client Protocol connects a coding agent with a client application such as an editor. This matters because a developer may want the navigation and review experience of one editor while using an agent from another vendor. The editor can present sessions, messages, file changes and approval requests. The agent can retain its own model choice, tools, account and runtime. The protocol is an interoperability layer between those roles.
Think of the editor as a workbench and the agent as a worker using agreed signals. The workbench does not automatically know how the worker thinks, and the worker does not inherit all of the workbench's policies. That separation is valuable for flexibility, but it requires careful setup when credentials and data are involved.
What the client can make visible
An ACP client may render the agent's messages in an editor panel, show proposed actions and help the user review changes. The exact experience depends on both implementations. A graphical session can keep the human close to source files and diffs without forcing the agent provider to build a full editor. The editor can also keep familiar keyboard shortcuts, language services and debugging tools.
Visual integration does not guarantee better decisions. An external agent may still search the wrong file or run an unsuitable command. Judge the integration by whether you can see the active project, understand what the agent wants to do, inspect the result and recover from a mistake. If the client hides an important part of the agent's execution, the convenience may weaken review.
What remains with the agent
The external agent may authenticate separately, select its own provider, assemble context and account for tokens under its own pricing rules. Installing it into an editor does not transfer usage into the editor's subscription. It also does not make the agent's data retention or logging policy identical to the editor's. Confirm the active account and model route before working on a sensitive repository.
Permission prompts can cross the boundary too. The client may display a request, while the agent decides when to request a tool. Check which component enforces a denial. A pretty approval dialog is insufficient if the runtime can perform equivalent work through another path without asking. Test with an innocuous read and a clearly mutating action to understand the distinction.
ACP is not a tool server protocol
MCP gives an AI application a standard way to discover and call external tools or read resources. ACP gives an editor and an agent a way to conduct a session. These edges can coexist. For example, an ACP agent displayed in an editor might consult an MCP documentation server, then propose a patch. The editor-agent session and the agent-documentation call are separate relationships.
This distinction helps diagnose problems. If the agent cannot appear in the editor, inspect the ACP client and agent setup. If it appears but cannot query documentation, inspect the MCP server and credentials. If it can query but makes a bad patch, inspect the repository evidence, model behavior and verification. Saying that the AI integration is broken is too broad to help.
A practical setup evaluation
Choose a disposable test repository. Connect one known agent to a supported client, open a small bug and ask for a read-only explanation. Verify which files the agent actually read. Then request a narrow edit, inspect the diff and run the relevant test. Note whether the client preserves the conversation and whether approvals arrive with enough context to make a decision.
Repeat the exercise after restarting the editor. Does the session restore? Does it reconnect to the right working directory and account? Are uncommitted edits still visible? The protocol is useful when the handoff feels like a coherent development workflow, not merely when a chat box can display messages.
Security and privacy questions
Document where the agent process runs, what repository content it can inspect and which endpoints receive model requests. If the agent can invoke a terminal, identify sandbox limits and environment variables it can see. A client may sandbox its own built-in features while an external agent uses a different process. The same editor window is not proof of a single trust boundary.
Use project-specific credentials where possible. Avoid exposing production secrets during first setup. Inspect logs and session history if your organization has retention requirements. An agent integrated through ACP can still use MCP servers, browser tools or remote workspaces; include those in the data-flow review rather than assuming the client screen is the whole system.
Where Licuse stands today
Licuse's current public workflow is its integrated IDE and its supported model routes. It does not advertise a general ACP host for plugging arbitrary external agents into the workspace. That is a product boundary, not a criticism of the standard. If a general external-agent interface is essential, choose a client that documents it and verify your chosen agent there.
If you are choosing between a built-in agent and an ACP combination, test the same task. Compare code navigation, context selection, command review, final diff and total billing. Interoperability is valuable when it lets you keep a strong editor while changing agents without losing visibility over the work.
ACP can let you bring an agent to an editor, while each agent keeps its own trust and billing boundaries.
Sources & further reading
References support the concepts and product descriptions discussed above. Features, prices and account eligibility can change; check the live documentation. Inclusion here is not a hands-on test or vendor endorsement.