What is the recommended ACP-standard mechanism for "send me a file" channel actions?

[mgaitan]

Draft Discussion: Standard way to handle "send me a file" in ACP clients

Hi ACP maintainers and implementers,

I am building a Telegram ACP client and I am trying to support a very simple user intent:

"Send me a file"

In practice, this is harder than expected when the file must be delivered by the client/channel (Telegram), not only referenced in model text.

Context

• Project: telegram-acp-bot (Telegram client + ACP agent bridge)
• Current implementation uses a client-local MCP server (telegram_send_attachment) to deliver files/images to Telegram.
• This works, but feels like a workaround because session routing and argument availability are not always obvious.

Related references:

• Closed discussion in codex-acp: Support ACP client extension methods (ext/method) for channel features like Telegram attachments zed-industries/codex-acp#173
  • I opened it asking about ext/method support, then closed it after realizing client-side support alone is not enough if the runtime/agent does not call those methods.
• My earlier client attempt via ACP extension methods (ext/method) for _telegram/send_attachment:
  • feat: explicit ACP attachment extension for Telegram (#33) mgaitan/telegram-acp-bot#55

Problem statement

From a protocol/user perspective, "send me a file" should be straightforward.

From an implementation perspective, today we have multiple non-ideal options:

1. Client-local MCP tool (current approach)

   • Pros: works with existing tool-call model.
   • Cons: needs implicit session/chat routing heuristics when tool input does not carry enough context.

2. ACP ext/method for channel actions

   • Pros: explicit client-side action model.
   • Cons: unclear discoverability and invocation path across runtimes.

3. Text conventions (example: attach://... prefixes in model output)

   • Pros: easy to prototype.
   • Cons: not standardized, fragile, and easy to break across clients/agents.

Main question

What is the recommended standard ACP mechanism for channel-side effects like attachment delivery?

Concretely:

• Should clients expose this via ext/method and expect runtimes to bridge it?
• Should ACP define a standard attachment action primitive for client channels?
• Should MCP be the canonical path, and if so, how should session/context be propagated to avoid ambiguity?

Clarifications I am looking for

1. Capability negotiation

   • How should a client advertise "I can send attachments to the end user channel" in a way that agents can reliably consume?

2. Invocation path

   • Which layer is expected to decide and execute the action: runtime, model tool call, or ACP extension bridge?

3. Context propagation

   • If MCP is used, what context should be guaranteed for each call (session id, chat/channel id, request id)?

4. Interoperability expectations

   • Is there guidance for making this work consistently across ACP agents (Codex, Gemini, Claude adapters, others)?

Why this matters

This is a common UX requirement for channel clients (Telegram, Slack, Discord, etc.).
Without a clear standard path, each client invents its own workaround and behavior diverges.

I would appreciate pointers to existing guidance, or direction on where ACP should evolve to make this use case first-class.

[morozow]

@mgaitan stdio Bus makes sense into external workers composition either telegram or any external provider.
Kernel stdio Bus repo: https://github.com/stdiobus/stdiobus
Workers registry: https://github.com/stdiobus/workers-registry

Your issue solution is not hidden under complex design and long road implementation. You can build easy nodejs, python, strict bash script to evaluate and to resolve income NDJSON which contains your specification schema (e.g., telegram schema); + sessionId which gives stdio Bus knowledge where should be worker response.