Using AI Coding Agents in Chat Tools: Architecture, Multi-Agent Collaboration, and Security

From “Always at the Workstation” to “Assign Tasks from Anywhere”

When using AI coding agents, commonly referred to as “agents” below, developers often rely on command-line tools in a terminal or plugins inside an IDE. These tools run on a machine with a properly configured environment and support deep development work.

This model works well for focused engineering sessions, but it breaks down once a developer leaves the workstation. A build failure may appear in an alert channel, a teammate may ask why a piece of logic was written a certain way, or a new project member may want to understand a module structure. If the agent is only available locally, these questions have to wait until the developer returns to their computer.

At the same time, code, logs, and documentation already live in chat tools. Agents, however, usually do not. This creates a natural idea: can developers invoke their preferred agent directly inside a chat window, using the model they prefer?

The core capabilities behind this idea include:

• integrating multiple types of agents,
• reaching them across different chat platforms,
• enabling multi-agent collaboration, and
• supporting runtime control.

A mature bridging solution usually supports several types of agents with different operating models:

• Terminal agents: These run through command-line interfaces. They can read and write files directly in a code directory and execute commands. They are powerful, but they also carry the highest permission risk.
• IDE-embedded agents: These are deeply integrated with editors and are good at completion and local refactoring. Their capabilities become limited once they are separated from the IDE.
• Cloud autonomous agents: These run tasks with longer chains in isolated remote environments, such as moving from a requirement description to code changes and verification.
• Protocol-based agents: Any tool that implements a common agent client protocol can be integrated. In such protocols, the client is responsible for interaction, while the agent side provides standard interfaces for session management, tool invocation, and permission confirmation. Integrators only need to implement the corresponding adapter logic.

Compared with terminal or IDE entry points, chat windows have a natural advantage: they support multi-person collaboration. Conversations can be searched, forwarded, and accumulated as team knowledge. Chat is also well suited to asynchronous task assignment: send a message now and check the result later.

However, chat should not replace an IDE for long, intensive coding sessions. Its role is better defined as an extension of the entry point and a supplement for collaboration.

Layered Architecture: Keeping Platform Differences Behind the Interface

There are many chat platforms. They differ in message formats, authentication methods, file limits, and Markdown support. If agent logic has to deal directly with every platform, the code will quickly become difficult to maintain.

A more reasonable approach is to split the bridge layer into three layers:

Chat platform (direct/group chat, slash commands, @mentions, file messages)
        │  Platform events (incoming)               ▲  Replies (outgoing)
        ▼                                             │
┌─────────────────────────────────────────────────────┐
│ Adapter layer: message normalization / identity mapping / reply rendering │
└───────────────────────┬─────────────────────────────┘
                        ▼
┌─────────────────────────────────────────────────────┐
│ Session management layer: state storage / command parsing / routing and collaboration │
└───────────────────────┬─────────────────────────────┘
                        ▼
┌─────────────────────────────────────────────────────┐
│ Execution layer: agent runtime / sandbox environment / model gateway │
└─────────────────────────────────────────────────────┘

• Adapter layer: Converts native platform events into a unified internal structure, such as “platform ID + session ID + sender ID + text/attachments + mentioned bot”, and then renders replies back into the formats supported by each platform.
• Session management layer: Stores the agent type, model, working directory, and permission mode bound to each session. It parses control commands and decides which agent should execute a message, or how multiple agents should hand off work.
• Execution layer: Runs agents in an isolated environment and invokes models through a unified interface. Isolation can be implemented with independent containers or dedicated runtime accounts to avoid affecting other services on the host machine.

After layering, when a platform adds or changes its protocol, the modification is limited to the adapter layer. When a new type of agent is introduced, only a new runner needs to be added to the execution layer. The business logic does not need to change.

Session, Identity, and State: Let the Chat Window Remember Context

Distinguish “Who” and “Where”

Each chat message carries at least two pieces of information: “who sent it” and “which session it was sent in”. These correspond to different strategies:

• Direct chat: A one-to-one binding provides natural isolation. Configuration changes affect only that user.
• Group chat: Multiple users share the same session state. All members can see the agent’s replies. Sensitive information such as code snippets, logs, or keys may spread, so permission control is necessary.

It is recommended to maintain an independent configuration for each session, including:

• agent type,
• model,
• reasoning effort,
• permission mode,
• current working directory, and
• history directory stack.

In group chats, differentiated authorization can also be applied based on member identity. For example, only maintainers may be allowed to switch working directories or raise permission levels.

Context Accumulation and Cleanup

Multi-turn conversations depend on context accumulation. Plain-text chat platforms usually do not provide structured threads, so the bridge layer needs to maintain a backend mapping of “session ID → message sequence” and include the necessary history in each request.

The longer the context, the higher the latency and cost, and the more likely it is to hit limits. Therefore, the system should provide:

• Automatic cleanup: If the session has been idle for too long or the context exceeds its limit, prompt the user to start a new session.
• Proactive compression: Summarize overly long history, retain key conclusions, and discard redundant process details.
• Manual reset: Provide a command such as “clear context”.

Long Task Feedback, Concurrency, and Deduplication

• Long task feedback: An agent task may take tens of seconds to several minutes. The system should first reply with an acknowledgment such as “Received” and send the result after the task is completed. If the platform supports message editing, the response can be updated in place.
• Task queue: Concurrent tasks in the same working directory may cause file conflicts. Tasks should be serialized into a queue, or each task should use an independent working copy.
• Message deduplication: Platform retries or network instability may cause duplicate delivery. Idempotency should be based on “platform + message ID”.

Integrating Multiple Agent Types: Abstract a Unified Capability Surface

To provide a consistent experience in chat windows, the bridge layer needs to abstract a set of common capabilities that each runner can implement.

Capability	Terminal agent	Cloud autonomous agent	Protocol-based agent
Start session	Start a local process and bind a code directory	Request a remote runtime environment and synchronize code	Establish a standard protocol connection
Send message	Write to process input	Submit a task	Send a session message
Receive streaming output	Read process output	Poll task events	Receive notification events
Tool and permission confirmation	Intercept high-risk command requests	Follow platform policy configuration	Respond to permission confirmation requests
End session	Terminate the process	Release the environment	Close the connection

The value of a unified capability surface is that users experience consistent interaction. Switching backends simply means switching to another runner and does not interrupt their usage habits.

A unified entry point is also needed at the model level. The bridge layer can include a “model gateway” that hides differences between inference service interfaces and exposes only a unified calling method. This makes model switching a configuration change and enables task-based routing. For example, complex reasoning can be sent to a stronger model, while simple batch tasks can be sent to a lightweight model.

Multi-Bot Relay: Let Multiple Agents Hand Off Work in the Same Session

In chat scenarios, the most intuitive form of multi-agent collaboration is to bind multiple bots in the same group chat, with each bot backed by an agent.

There are three common orchestration modes:

1. Routing mode: Only one bot acts as the entry point in the group. Messages are forwarded to different backends based on commands or question type. Users have a simple experience, but group members see only a unified output and cannot directly tell the source of each response.
2. Relay mode: Multiple bots are present at the same time. Messages are distributed according to rules and results can be passed along between agents. The collaboration process is visible to everyone, which is suitable for solution review and cross-validation.
3. Orchestration mode: A coordinator splits tasks, distributes them to executors, and finally aggregates the output. This is suitable for more complex tasks, but the implementation cost is significantly higher.

The key point of relay mode is not merely “forwarding messages”. It is whether context can be passed safely between multiple agents.

A typical collaboration flow is as follows:

Member asks for code review
   → Review agent: identifies issues and risks
   → Fix-suggestion agent: proposes changes based on review feedback
   → Model A: points out potential side effects and adds test suggestions
   → Model B: adds comments from performance and maintainability perspectives
   → Bridge layer aggregates the results and organizes conclusions by the member’s concerns

Routing and Loop Suppression

Each agent should be bound to a “call name”, specified through an @mention or message prefix. If no target is explicitly specified, the session’s default agent is used.

Loop protection is mandatory: agent output must not trigger routing again. Otherwise, multiple bots may enter an infinite conversation.

Practical constraints include:

• a maximum number of relay rounds for a single message,
• an overall time limit, and
• allowing only human members to initiate new tasks.

Shared Context and Conflict Handling

When the same question is sent to multiple agents, later agents should be able to see the conclusions of earlier agents. Otherwise, the responses are merely parallel and do not constitute collaboration.

A common implementation is to inject the previous round’s output into the next round’s input as a “quoted message”.

However, context contamination must be watched for: an incorrect conclusion from an earlier step may be treated as established fact and passed forward. A safer approach is to clearly distinguish between “hypotheses to be verified” and “confirmed conclusions” in the prompt.

If multiple bots respond to the same message at the same time, they should reply in the order of their call names, and the number of concurrent responses should be limited to avoid flooding the chat.

Cost and Rate Limiting

Multi-agent relay means that a single question may trigger multiple inference calls. The bridge layer should provide quotas such as:

• maximum number of agents per session,
• number of calls per hour, and
• daily cost limit.

It should also periodically output usage statistics.

Bring Terminal-Style Controls into Chat

Terminal tools usually provide a set of slash commands for adjusting behavior during execution. The bridge layer needs to translate these into chat commands.

The commands mentioned here are generic examples. Different implementations may use different syntax.

Category	Example commands	Purpose
Model and reasoning	Switch model; adjust reasoning effort	Balance quality, latency, and cost
Working directory	Switch to a specified directory; jump by number; return to the previous directory	Move quickly between code repositories
Session and context	Clear context; view current configuration	Manage state
Permissions and runtime	Switch permission mode; terminate current task	Control what the agent can do

Switch Model and Reasoning Effort

Different models are good at different tasks. Some are better at understanding long text, while others generate responses faster.

The same model may also offer different reasoning effort levels. Higher effort usually produces more reliable answers for complex problems, but it also increases latency and cost.

The bridge layer can maintain a mapping from “alias → actual model” so users do not need to remember long model identifiers. If the gateway encounters an unknown alias, it should reply with the list of available options rather than returning an error.

Switch Working Directory

/dir <path> determines which repository or subdirectory the next session works in. /dir <number> and /dir - allow quick jumps between historical directories, which is much more efficient than re-entering long paths.

This type of switching is security-sensitive and should include three checks:

• Directory allowlist: Only switch within authorized code root directories.
• Relative path normalization: Resolve paths to absolute paths before switching to prevent unauthorized access through ...
• State validation: Before each task starts, confirm that the directory still exists and is readable.

Switch Permission Mode

Execution-capable agents usually have tiered permission modes, such as:

• plan mode,
• confirmation mode, and
• automatic execution mode.

This is especially important in chat scenarios. In a terminal, confirmation is performed by the operator. In chat, commands may come from multiple people. The bridge layer must ensure that the person who enabled a high-risk permission can be traced to a specific member and should default to a conservative policy.

Access from Private Networks Without Public IPs

Many teams run agents on machines inside private networks. These machines may not have a public IP address or a registered domain.

Mainstream chat platforms generally provide two integration approaches:

• Event subscription: The platform pushes messages to a specified address. This requires a public HTTPS endpoint.
• Long-connection or local gateway mode: The client actively connects to the platform, and messages are transmitted bidirectionally over the established connection. No inbound ports need to be opened.

For private network environments, the latter approach is usually preferred. If event subscription must be used, a lightweight gateway can be deployed in the cloud and connected to internal services through a reverse tunnel, while still maintaining unified authentication, rate limiting, and logging.

It should be noted that whether an agent can be deployed without a public IP depends on the integration method provided by the chat platform used. This is not a universal conclusion.

Security and Permission Boundaries: Do Not Skip This Section

Integrating an agent that can read and write files or execute commands into a chat tool creates a security model completely different from that of a traditional bot. It is recommended to protect across five layers:

1. Identity and access control: Only authorized members can invoke the agent. Roles can distinguish read-only access from execution access. By default, group chats should only allow viewing results.
2. Least privilege: Agents should run under low-privilege accounts by default and can access only specified directories. High-risk operations, such as deleting files, executing installation scripts, or pushing code, require human confirmation or are allowed only in explicitly enabled modes.
3. Credential management: Model keys and platform keys should be stored in a secret management service or environment variables. They must never appear in chat content, logs, or exception stack traces.
4. Data boundaries: Before code or logs leave the internal network, compliance requirements should be evaluated, and masking should be applied when necessary. For sensitive scenarios, a model service deployed in a dedicated environment can be selected.
5. Prompt injection protection: Malicious text in repository comments, code documentation, or issue descriptions may induce the agent to perform dangerous operations. In addition to least privilege, network egress should be restricted to only necessary addresses.

In addition, the bridge layer should record complete audit logs, including:

• who invoked the agent,
• in which session,
• which agent was called,
• which model was switched to,
• which tools were executed, and
• which directories were accessed.

This is useful for troubleshooting and also forms the basis for security accountability.

Typical Use Cases

• On-call troubleshooting: After an alert notification enters an on-call group, a troubleshooting agent reads recent commits, build logs, and runtime logs, and provides an initial diagnosis direction. When a maintainer asks follow-up questions, an agent with execution permissions can verify hypotheses in a test environment.
• Code review: After a review request is submitted, multiple bots provide feedback from different models and review perspectives. The bridge layer deduplicates and aggregates the feedback, and reviewers can ask follow-up questions in the same conversation.
• New member onboarding: A new member can ask in the group, “Where is the entry point for this module, and what is the call chain?” A read-only agent can answer based on the repository and documentation, reducing interruptions to senior colleagues.
• Task assignment and receipt: Send a requirement description to a cloud autonomous agent. The agent completes code changes and verification in an isolated environment. Progress is sent back as messages, and a change summary is attached after completion for human review.

Rollout Steps and Common Mistakes

Rollout steps:

1. Define the boundary: Start by integrating only read-only question-and-answer agents. Validate platform connectivity, identity mapping, and audit capabilities.
2. Implement core commands: Implement model switching, directory switching, context cleanup, and permission mode switching, with allowlist validation.
3. Introduce execution capabilities: Run agents with file read/write capabilities in an isolated environment, defaulting to confirmation mode, and gradually expand authorization scope.
4. Extend to multi-agent collaboration: Configure routing and relay rules, and add loop protection and quota limits.
5. Measure continuously: Track response latency, task success rate, cost per task, and number of high-risk operations. Use these metrics to adjust model routing and permission policies.

Common mistakes:

• Treating a group chat as a personal terminal and performing sensitive operations in a conversation visible to many people.
• Failing to control concurrency, causing multiple tasks to modify the same directory and produce chaotic results.
• Optimizing only for connectivity while ignoring message deduplication, timeout retries, and long-task feedback, leading to an unstable experience.
• Simply adding multiple bots to a group without routing rules, causing them to flood the conversation.
• Using a personal account to host a shared service for a long time. Once the account changes, the service is interrupted.

Conclusion

Bringing AI coding agents into chat tools is essentially about adding an entry point for collaboration and mobile scenarios beyond the terminal and the IDE.

The key is not how many types of agents or platforms are supported. What matters is:

• whether abstraction is clear, including a unified message model, capability surface, and model gateway;
• whether state is reliable, including persistent management of sessions and permissions;
• whether collaboration is controllable, including routing, relay, and loop protection; and
• whether security boundaries are solid, including identity, permissions, auditing, and data compliance.

Once these layers are firmly established, the chat window can remain a stable unified entry point for team and agent collaboration, regardless of which type of agent or model is used underneath.