A deep-research pass run 2026-07-29 as one workstream of the Smith & Clara audit. Question: coordination, turn-taking, dedup, backchannels, auditability and plain-text-vs-protocol for multiple agents in one Slack workspace — plus identity, silence, escalation and injection hardening for agents designed as teammates.
109 agent calls · 6 research angles · 26 sources fetched · 130 claims extracted · 25 taken to adversarial verification · 8 confirmed, 17 killed, 0 left unverified · 9 findings after synthesis. Verification is a 3-vote adversarial pass; every finding below carries its vote. Findings whose votes were reinstated after the synthesizer re-read the primary text say so explicitly and explain what the refutation actually hit.
One clean empirical answer on coordination, and a firmly negative one on protocols.
On turn-taking: layering an explicit addressee-based handoff (“current speaker names the next speaker”) on top of self-selection significantly reduced dialogue breakdowns versus both round-robin and pure self-scored-importance gating — breakdowns per 10 turns went from a 1–8 spread to a distribution centred on 1 (Kruskal-Wallis χ²=42.171, p<0.001) — while pure marginal-value gating produced exactly the failure modes this audit was looking for: one high-scoring agent monopolising 7 of 10 turns, and a verbatim duplicate utterance. So “ownership locks vs marginal-value gating” resolves to neither alone: an explicit named handoff layered over a value gate, with silence made a first-class logged action rather than the absence of one.
On structured protocols: unambiguous. Across MCP, A2A, ACP, ANP and ERC-8004, voting, dissent preservation and human escalation are universally Absent; audit is Partial at best and an accident of the substrate rather than a design; ACP's sole deliberation support explicitly “lacks turn-taking governance, relevance enforcement, or synthesis primitives”; no protocol exceeds 2/12 governance coverage. Turn-taking, dedup, escalation and human-auditable deliberation logs must all be app-level. Adopting A2A/ACP/MCP buys this system nothing for coordination.
On security — the best-evidenced strand: inter-agent messaging is modelled as a first-class attack surface distinct from agent-to-tool safety, with named classes for compromise that propagates between peers, and the confused-deputy exfiltration pattern is publicly demonstrated, catalogued in MITRE ATLAS with a Slack-native instance, and still working in July 2026 after vendor guardrails were added.
On teammate norms: Slack's own guidance supplies them (reply in threads, emoji-react for bare acknowledgment, batch related notifications, immediate-then-progressive status, function-first naming, clearly non-human avatar, on-behalf-of labels, confirmation for real-world writes counterweighted by an anti-fatigue warning) — but explicitly declares agent-to-agent handoffs “still being defined and under exploration.” There is no platform-blessed multi-agent pattern to inherit.
The caveat that dominates all of it: the single quantitative coordination result comes from 4 synchronous agents playing a murder-mystery game with GPT-4 as both generator and judge and no humans present. The direction is suggestive for a 2-agent asynchronous human channel; the effect size does not transfer.
Explicit addressee-based handoff layered on self-selection beats both round-robin and pure marginal-value gating. Pure self-scored-importance gating causes turn monopolisation and duplicate output — which makes the locks-vs-value-gating dichotomy a false one.
The strongest actionable result in the corpus. Nonomura & Mori, Who Speaks Next? Multi-party AI Discussion Leveraging the Systematics of Turn-taking in Murder Mystery Games (arXiv 2412.04937, Dec 2024; published in Frontiers in Artificial Intelligence 2025-06-17). Three conditions ablated: EQUAL (random order, equal utterance counts), SS (self-selection only — each agent emits speak/listen plus an integer importance 0–9, and the highest scorer takes the floor), and CSSN-or-SS (Current Speaker Selects Next, else self-select).
“In Turn 3, Kozue asks Yukiko ‘What were you doing?’ However, from Turn 4 to Turn 7, Kozue continues to ask questions. This pattern of consecutive questions from the same speaker without consideration for the second pair part of an adjacency pair was frequently observed. This is due to such an agent with high importance scores monopolizing turns.” The journal version puts it harder: “This example demonstrates the phenomenon of turn monopolization caused by importance-based turn allocation.”
In the actual transcript Kozue holds turns 3–7, yields once at 8, then takes 9 and 10 — 7 of 10 turns — and her turn-10 utterance is a verbatim duplicate of an earlier one. That duplicate is direct evidence that marginal-value gating alone does not dedup redundant output.
“In both the EQUAL and SS conditions, the number of utterances that led to dialogue breakdown per 10 turns showed a wide distribution from one to eight utterances”; “the CSSN-or-SS condition showed a narrow distribution centered around one utterance. Kruskal-Wallis testing revealed significant differences between conditions (chi2 = 42.171, p < 0.001).” Dunn's with Bonferroni: CSSN-or-SS beat EQUAL (p<0.001) and SS (p<0.001). Design: 4 agents, 50 sets of 10 turns per condition, GPT-4o / GPT-3.5-turbo.
The handoff must be explicitly named, never inferred. The addressee-recognition benchmark (arXiv 2501.16643, Jan 2025) finds LLMs “perform only marginally above the chance level in addressee recognition and below the chance level in the next speaker prediction task” — so a policy that infers who holds the floor is building on a sub-chance primitive. Corroborating pattern: AutoGen frames speaker selection as equalising utterance counts to avoid order effects, and the Virtual Roundtable work weights selection by “eagerness, participation volume, and stochastic elements” — a participation-volume penalty added precisely to stop a high-eagerness persona dominating.
4 agents, synchronous, exactly one speaker forced per turn, winner-take-all comparison, no humans in the loop, playing a murder-mystery TTRPG. Smith + Clara is 2 agents, asynchronous, threaded, humans present, persistent identity, and no scarce floor — both can post simultaneously without collision. The paper offers no evidence at all about threshold gating (“speak only if value > T”), which is what a 2-agent system would more likely implement than winner-take-all. The authors also report memory and topic-management degradation past ~30 turns.
And the headline metric is LLM-judged: breakdown labels come from GPT-4 applied to a breakdown taxonomy — GPT-4 both generates and judges. The separate human evaluation (Fleiss κ = 0.77) scored game-quality criteria, not breakdown labels. Table 1's taxonomy has no explicit “monopolization” category, so the p<0.001 statistics measure dialogue breakdowns in general, not monopolisation counts. One unresolved confound: in the SS condition, “when all agents select ‘listen,’ the previous speaker continues speaking” — so consecutive same-speaker turns may partly come from that rule rather than from importance comparison.
Make “stay silent” a first-class action with a required justification, not the absence of an action — an explicit WAIT tool plus forced tool choice makes silence both expressible and auditable.
SlackAgents (Salesforce AI Research, EMNLP 2025 System Demonstrations). Verbatim, appearing twice: “After sending a request, the agent executes the WAIT function, ending its tool request loop and awaiting responses from colleague agents. The proactive agent behavior is mainly achieved through this function.” And on silence specifically: “Based on the context and its capabilities, the agent determines whether to engage in the discussion or continue waiting for additional input… guided by a structured system prompt, which defines interaction rules, response guidelines, and criteria for silence or engagement.” A figure caption reads: “Proactive channel assistant monitors the messages in slack channel and decide to keep silent or chime in to help,” with the rendered reasoning column showing “This is a regular conversation between humans. I need to keep silent.”
Schema: wait is a real tool — {"name": "wait", "description": "Wait for the next message.", "parameters": {"reason": {…}}, "required": ["reason"]} — with a required free-text justification, which is exactly what makes the silence decision auditable after the fact.
Code, stronger than the paper: the assistant sets tool_choice="required" and unconditionally appends the wait tool to every assistant, so the model must emit some tool call each step. Silence is literally inexpressible as an absence; it can only be uttered by calling wait with a reason.
(1) Demo-track paper, lightly reviewed, zero evaluation — no precision/recall on engage-vs-silence anywhere. (2) The paper hedges “mainly” / “primarily”: WAIT is the action primitive while the engage-vs-silence decision is prompt-driven, so WAIT is a turn-yield mechanism, not a silence policy. (3) Design-versus-implementation gap: execute() handles wait with continue inside the for over tool calls, which does not break the enclosing while — so it re-calls step() and spins to max_steps. “Ends the tool loop” is prose, not shipped control flow. (4) The proactive-monitoring machinery is unreleased — no handler, no structured silence-criteria prompt — so that half is unverifiable in code.
Decentralised in-thread @mention delegation between peer agents is a documented design position argued by analogy to human coworkers — but it is asserted, never measured, and “in-thread” does not by itself deliver human auditability.
Verbatim, twice: “Compared with the ‘handoff’ strategy in OpenAI swarm, which hands off all messages to another agent by swapping system prompt and tools, our collaboration strategy is decentralized, asynchronous, and scalable by leveraging Slack-specific functionalities, and importantly, same as how human workers collaborate in Slack channels by looping in colleagues for help in threads.” The mechanism is concrete: produce a message containing a request @mentioning chosen agents/humans from a pre-defined colleague list, send it to the colleagues in a dedicated session, listen for responses — backed by three tools per assistant (SEND_MESSAGE, WAIT, GET_THREAD_HISTORY).
(1) No evaluation exists. Nothing on evaluate/experiment/baseline/benchmark/accuracy/success-rate beyond the introduction, and the Limitations section is four generic bullets that never touch coordination. Do not cite this as evidence that decentralised @mention outperforms handoff — cite it only as a documented design position. (2) Stale baseline — the paper's own bibliography calls Swarm “an educational framework,” since superseded, so the contrast is drawn against a deprecated non-production target. (3) “Asynchronous” is the paper's word, but WAIT works by “ending its tool request loop and awaiting responses” — a yielding block. (4) Most important for the backchannel question: the main body routes the request to colleagues “in a dedicated session,” so deliberation may occur off the originating user thread — and correspondingly the stronger corollary that “all inter-agent traffic stays human-visible and auditable in-channel” was refuted 0-3 by the verification pass.
Conclusion for this system: whether inter-agent deliberation is human-visible is an implementation choice you must make and log deliberately, not a property you inherit by using @mentions.
No agent interoperability protocol supplies the primitives this system actually needs. Turn-taking, dedup, human escalation, dissent and decision-reconstruction are all app-level; auditability is Partial at best and an accident of the substrate — so a human-auditable inter-agent deliberation log has to be designed as an app-level log.
Kang & Diponegoro, Governance Gaps in Agent Interoperability Protocols: What MCP, A2A, and ACP Cannot Express (arXiv 2606.31498, 2026-06-30 — one month old at time of research).
“Audit as substrate property (G6). Where audit support exists, it derives from the underlying infrastructure (blockchain immutability for ERC-8004, session state for MCP) rather than from deliberate governance-audit design. No protocol defines governance-specific event types, decision-reconstruction semantics, or replay guarantees.” On MCP: “G6 Audit: Partial… However, there is no tamper-evident event log, no hash chain, and no replay guarantee. Audit depends on implementation, not protocol specification.”
Table III, scored Supported=2 / Partial=1 / Absent=0 across six governance dimensions: MCP v1.1 1/12 · A2A v1.0.1 1/12 · ACP 2/12 · ANP 0/12 · ERC-8004 2/12. G3 Voting, G4 Dissent and G5 Human escalation are Absent for all five — “Voting, dissent preservation, and human escalation are absent across all five protocols.”
Directly on turn-taking: ACP is the only protocol with any deliberation support and it is Partial — “ACP's negotiation patterns (propose, accept, reject, counter) constitute structured exchange with some challenge/response semantics. However, negotiation is bilateral… not multilateral deliberation… The protocol lacks turn-taking governance, relevance enforcement, or synthesis primitives.” On escalation: “G5 Human escalation: Absent. MCP's Elicitation feature allows servers to request human input during tool execution, but this is user-input solicitation, not governance escalation. There is no protocol-level mechanism for routing community decisions to human authority.” Empirical kicker: “After 6+ months of A2A being publicly available with an active extension ecosystem, zero governance extensions have been proposed or implemented.”
MCP revision 2026-07-28: utilities are Configuration, Progress, Cancellation, Error reporting; extensions are OAuth Client Credentials, Enterprise-Managed Authorization, MCP Apps, MCP Tasks — zero audit/provenance/replay/governance extensions, and the spec defers to the app layer (“While MCP itself cannot enforce these security principles at the protocol level, implementors SHOULD…”). A2A v1.0.0 actively disclaims the guarantees an audit trail needs: “Messages MUST NOT be considered a reliable delivery mechanism for critical information”; “not all Messages are guaranteed to be persisted in the Task history.” ERC-8004 attributes audit integrity to its substrate outright: “on-chain pointers and hashes cannot be deleted, ensuring audit trail integrity.” Independent corroboration of the structural point, O'Reilly's The AI Agents Stack (2026 Edition): “MCP standardized how agents use tools but says nothing about how agents talk to each other.”
The paper surveys five protocols; generalising to “any protocol” is its inference, not an exhaustive proof. And “accident of the substrate” slightly undersells ERC-8004, which does define structured events with hashes binding off-chain content — though those are identity and reputation, not decision reconstruction, hence its own Partial grade. Source quality: this is a 2-author arXiv preprint, presumably not peer-reviewed; it was upgraded only because its central claims are cheaply-checkable negatives about published specs, and they checked out against three current primary specs.
Agent-to-agent messaging is a first-class attack surface distinct from agent-to-tool safety, and compromise is modelled as propagating between peers rather than staying contained — so a two-agent Slack system must be threat-modelled on its inter-agent channel, not just on each agent's tool use.
Ferrag et al., From Prompt Injections to Protocol Exploits: Threats in LLM-Powered AI Agents Workflows — peer-reviewed and published in ICT Express (Elsevier). Abstract, verbatim: “This survey introduces a unified end-to-end threat model for LLM-agent ecosystems, covering host-to-tool and agent-to-agent communications. We systematically categorize more than thirty attack techniques…” The structural separation holds under scrutiny: the paper splits host-to-tool (MCP) from agent-to-agent (A2A), and the A2A-layer attacks have no host-to-tool analogue.
Cross-Agent Context Manipulation: “Context manipulation attacks exploit unvalidated state propagation between agents… the adversary injects delta_k such that K_i^{t+1}=f(K_i^t (+) delta_k, payload(m'_ji)), resulting in erroneous or malicious context influencing downstream decisions. This mechanism underlies cross-agent prompt injection, discovery spoofing, and replay-based corruption.” That formalism is literally agent j's message payload corrupting agent i's knowledge state.
Contagious Recursive Blocking: “Corba exploits two key properties: its contagious nature, which allows the attack to propagate across various network topologies, and its recursive property, which depletes computational resources over time. The attack typically involves seemingly benign instructions, making it difficult to detect and mitigate using traditional alignment methods.” This derives from an independent primary paper (arXiv 2502.14529), evaluated on AutoGen and Camel.
A grep note worth keeping: the paper uses U+2010, so an ASCII-hyphen search returns zero hits — a typographic artefact, not an absence.
(1) The paper studies formal protocols — agent cards, registration, task delegation. For Smith + Clara (no A2A, no agent cards, one shared Slack channel, one shared codebase) agent-card poisoning, fake registration and delegation DoS do not map. The one cleanly transferable finding is cross-agent prompt-injection propagation, which does apply to two agents reading arbitrary workspace messages. (2) The paper's own table says of CORBA: “Highlights need for stronger security in LLM-MAS; no concrete defense tested” — this source justifies the threat model and supplies no validated mitigation. Also note the paper argues for a unified model with distinct layers, so “must not be folded into tool safety” is rhetorically stronger than the source; the defensible reading is a distinct layer within one end-to-end model.
The confused-deputy exfiltration pattern — an agent reads attacker-authored content on a shared public surface and is hijacked into leaking private data its principal could see but the attacker could not — is publicly demonstrated, has a Slack-native catalogued instance, and was still working in July 2026 after vendor guardrails. The enabling precondition is auto-approved tool use plus untrusted input plus private scope.
Traced past the survey to primary sources. Invariant Labs (2025-05-26), against the official GitHub MCP server (14k+ stars): an attacker files a prompt-injection issue on a public repo; the agent, holding the user's PAT, reads the issue, then reads the user's private repos and publishes their contents into a PR on the public repo — leaking private repo names, salary and relocation plans.
PromptArmor's Slack AI indirect prompt injection (Aug 2024), formally catalogued as MITRE ATLAS case study AML.CS0035. An instruction planted in a public Slack channel caused Slack AI to exfiltrate API keys from a private channel the attacker had no access to. Identical confused-deputy shape, native to the exact platform in question, and in a formal threat catalogue.
Noma Security's “GitLost” (July 2026) shows the same pattern working against GitHub Agentic Workflows — public issue comment, agent with cross-repo read access, private contents posted publicly — and found that merely prefixing the payload with “Additionally” bypassed GitHub's added threat-detection guardrails. A parallel Azure DevOps MCP variant (hidden PR comments hijacking AI review agents) also landed July 2026. Implication: content inspection and keyword filtering are demonstrably not a control. The control has to be capability scoping.
Invariant states: “Claude Desktop by default requires the user to confirm individual tool calls. However, many users already opt for an ‘Always Allow’ confirmation policy.” The exploit landed under auto-approve. The transferable lesson is auto-approved tool use + untrusted input + private scope, not injection alone — directly relevant to an always-on Temporal-driven agent with no human in the approval path. Invariant also concedes the fix is architectural: “This vulnerability cannot be resolved through server-side patches. It requires architectural controls.”
(1) “Real-world” is imprecise — this is a researcher PoC against real production software, not an observed in-the-wild victim; prefer “publicly demonstrated against the production GitHub MCP server.” (2) A framing dispute exists arguing the “vulnerability” label “conflates architectural design with implementation error” — but nobody disputes the exfiltration occurred, only the attribution of blame to the protocol. (3) The mitigating principle is stated as Slack policy in Slack's own guidance: “An agent shouldn't be able to read, access, or use information that the invoking user wouldn't be able to access on their own,” extended explicitly to files, canvases, lists, Salesforce records and huddle transcripts.
Slack's own platform guidance supplies concrete post-vs-react-vs-silent, thread-discipline, batching and status norms — and explicitly states that agent-to-agent handoffs are unsettled, so there is no platform-blessed multi-agent coordination pattern to inherit.
Why it is here despite the vote: the synthesizer re-read the fetched page text and the prescriptions below are verbatim present. The refutations correctly targeted modal overreach and one unsupported gloss, not the content. The corrected phrasing is what is kept.
Thread discipline: “Agent responses should be made in threads. This prevents flooding the main conversation.” And: “DMs can be more conversational but responses in channels should be minimal and added as threads to reduce unnecessary notifications. If the agent is sharing private information, send it only through DMs, private channels, or ephemeral messages.”
React instead of post: “For simple acknowledgments, a lightweight signal like an emoji reaction can confirm the agent saw a message without adding noise.” Cited example: “Linear posts the created issue and reacts to the original message with a checkmark.” This is the platform's own low-noise alternative to speaking — the natural third option alongside post and stay-silent.
Batching (the closest thing in the corpus to a dedup rule): “Organize related notifications into batches. Five issue updates should be one message, not five.”
Status: “Show a status indicator immediately after the user sends a message. This can range from a lightweight emoji reaction to a ‘Working on it…’ status.” “Update the status as the agent progresses.” “Keep status messages brief. They should be glanceable, not paragraphs.” Plus: “Multi-step tasks use plan blocks to show a list of steps where the agent is making decisions, not just fetching data”; “Make plan blocks collapsible or visually secondary to the final output.”
Audience awareness, directly relevant to two agents sharing a channel: “In channels, be audience-aware. The agent may have context from a DM or another channel that isn't appropriate to surface publicly.”
The multi-agent gap, verbatim from the page's final note: “Agent experiences on Slack, and on every platform, are moving fast. These guidelines reflect where things stand today. Some newer interaction patterns like ambient agents and agent-to-agent handoffs are still being defined and under exploration. Think of this as a living document.” The page contains no prompt-injection hardening guidance and no A2A/MCP coordination guidance.
Slack describes a status mechanism (plus plan blocks, task updates and text streaming). It is not a prescription to post a placeholder message and later edit it — that gloss is unsupported by the page. Any argument that Slack validates post-then-edit placeholders is wrong.
Source-quality caveat: this is vendor normative documentation — first-party authoritative for the platform, but not empirical, with no evaluation behind any prescription, and self-declared time-sensitive.
Slack's identity guidance is function-first naming, a clearly non-human avatar, and never letting a user wonder whether they are talking to a human — which puts human-style persona names in direct tension with platform guidance. Nothing in the corpus addresses persona separation for multiple identities sharing one runtime.
“First and foremost, users should not have to question whether they are talking to a human or an automated system.” “Lead with function, not personality. Names like ‘Recruit Assistant’ or ‘Deal Desk’ tell users what the agent does at a glance. Human-first names can blur the line between person and agent.” “Choose an avatar that is distinguishable and appropriate. It should be clearly non-human, and match its purpose.” “Write a description that states what the agent does, not what it is.” And on acting for a human: “Label actions clearly with ‘on behalf of [user]’…”; “When the agent creates content autonomously without the user reviewing it first, include a visible indicator that the content is AI-generated and hasn't been reviewed”; “Give users a review surface in the App Home so they can see what the agent has done on their behalf.”
“Agent Smith” and “Clara” — and “Trinity” — are all human-style persona names, which is exactly what this guidance warns blurs the human/automation line, and a realistic Matrix-character avatar cuts the same way. That remains a defensible product choice; it should be a recorded, deliberate deviation, compensated elsewhere (function-stating description, AI-generated labelling, App Home review surface) rather than an unexamined default. This matters more the closer a bot sits to customer-facing channels.
Across every source in this corpus — both Slack pages, SlackAgents, the turn-taking paper, both security papers, the governance-gap paper — nothing addresses persona separation for identity-parameterised instances of one codebase sharing a runtime. SlackAgents comes closest architecturally (a colleague list plus per-assistant prompts and tools) but never treats cross-persona leakage, shared prompt/state contamination, or per-persona credential scoping as a problem. This part of the question is unanswered by the literature found, not answered negatively — which means the agent_ident seam is ahead of the published literature rather than behind it.
Human confirmation for real-world writes is prescribed but explicitly counterweighted by an anti-fatigue / bounded-autonomy warning — it is a “should” with a scoping rule, not a hard gate on every action. Escalation-to-human must be built at the app layer, because no protocol defines it.
“Any action with real-world output (e.g. sending an email, approving an action, updating a record) should require explicit human confirmation. Agents can make mistakes and hallucinate. Design for this failure up front… Give them the ability to undo actions taken by your agent and a way forward so they're not stuck with the failure. Make sure the user, not the agent, is in the driver's seat.” On auditability: “make sure every action taken and decision made is accessible to the user. They should be able to easily tell what the app does, when it does what it does, and why it does what it does.” “When there is a failure, make the error auditable.” Its four named requirements: predictability, transparency, control, safety — with “permission scopes and least privilege design” called out under predictability.
“Be cautious, asking for confirmation on every action creates fatigue and trains users to click through without reading. Save confirmation for moments that actually need it.” And the whole bounded-autonomy section: “If you're overly cautious and provide too many constraints, you may limit the capabilities and value that an agent can provide. In contrast, giving an agent too much autonomy and access may risk exposing sensitive data or taking inappropriate actions… Developers give the agent a goal and the freedom to figure out how to achieve it, but also set clear boundaries around what it can and cannot do without asking.” Plus “Build strong defaults with flexibility over time.” The modal verb throughout is “should,” never “must.”
The agent-design page prescribes “Offer 2-3 clear next steps: retry, modify the request, or escalate,” distinguishes capability limits from transient errors (“‘I'll never be able to delete issues’ is different from ‘Agent is temporarily unavailable’”), and requires naming skipped steps with reasons. Cross-referencing F4: G5 Human escalation is Absent in all five protocols, and MCP's Elicitation is “user-input solicitation, not governance escalation.” So the escalation trigger conditions, the routing target, and the log that proves escalation happened are all things this system must define itself.
ADR 0004 — Sibling coordination: leader + reviewer, deliberation channel — was authored and merged the same night (agent-smith docs/adr/0004-sibling-coordination-protocol.md, PR #125, merged by Gera after Fede's “ship it”). Mapping each finding onto it, honestly, including where the ADR goes past the evidence and where the evidence goes past the ADR.
Rule 1 makes an @mention an ownership lock with topic-lane routing for un-addressed messages; rule 2 makes the sibling a reviewer that “posts ONLY a correction or a net-new angle; otherwise it reacts (👍) or stays silent,” on a bar that is “qualitative (correction / net-new / nothing), never a self-scored %.” That is the named-handoff-plus-value-gate combination F1 found beats both round-robin and pure value gating — and the explicit ban on a self-scored percentage is precisely the SS condition the paper showed monopolising turns and emitting a duplicate. The ADR also rejects a pre-speak distributed lock and a scored election service at N=2 and defers them to 4+ agents, which is the right call on this evidence.
Where it goes past the evidence: topic-lane routing of un-addressed messages is inference, not an explicit named handoff — and F1's corollary is that LLMs are marginally above chance at addressee recognition and below chance at next-speaker prediction. The lane rule may misfire exactly where it matters most, since 6 of 7 observed duplicate pairs were on un-addressed messages.
Rule 3 — “Never post to announce non-participation” — kills the narrated-silence anti-pattern outright, and rule 2's react-or-stay-silent is Slack's own low-noise alternative from F7. Good.
What is missing: F2's actual finding is stronger than “silence is silent.” It is silence is a logged action with a required reason — a WAIT-shaped primitive where abstention cannot be expressed as an absence. ADR 0004 makes silence invisible rather than auditable, so a human reviewing the thread cannot reconstruct why a sibling stayed out. F7's batching prescription (“five issue updates should be one message”) is not addressed at all.
Rule 5 mandates plain terse text in #agents-only, “structured fields over prose, no pleasantries, no custom machine encoding (same-model agents gain ~nothing from one; humans lose auditability).” The conclusion is right. In the thread it was reached via an information-theory justification that was preference dressed as fact; F4 supplies the real reason — no protocol supplies turn-taking, dedup, escalation, dissent or decision reconstruction, so all of it is app-level anyway and a machine encoding buys nothing while costing human auditability.
ADR 0004 adds a backchannel (#agents-only) and leans on the existing sibling rail, without threat-modelling either. F5 says compromise propagates between peers; F6 says the confused-deputy exfil pattern is live, Slack-native, catalogued, and survives keyword guardrails — which lines up one-to-one with the audit's P0-5 (no sender allowlist, the quoted transcript excluded from injection screening, a bypassPermissions brain with HOME passed through). F6's transferable lesson is that the control is capability scoping, not content inspection. Nothing in ADR 0004 touches capability scope.
Rule 7 asserts that keeping all coordination in Slack makes it “auditable by construction… logged by the conversation-log invariant,” with no off-Slack backchannel. F3's human-visibility corollary is the one claim in the corpus that was refuted 0-3: in-thread @mention traffic is not inherently human-auditable, and whether deliberation is visible is an implementation choice you must make and log. Worse, the audit's P0-1 shows the invariant rule 7 leans on is a shared unslugged file that writes Clara's rows labelled “Smith.” The trail exists; it is mislabelled. Keeping deliberation in Slack is the right instinct — but “by construction” is doing work the evidence does not support.
Function-first naming, a clearly non-human avatar, and never letting a user wonder if they are talking to a human. Smith, Clara and Trinity are all human persona names, and a realistic Matrix-character avatar compounds it. The recommendation is not to abandon the personas — it is to make this a recorded deviation with compensating controls (a function-stating description, AI-generated labelling, an App Home review surface), especially for a bot that sits near customer-facing channels. Note F8's other half: persona separation on a shared runtime is addressed by no source at all, so the agent_ident seam is ahead of the literature.
F9's honest reading — “should,” with an explicit anti-fatigue counterweight — means the audit's merge-gate P0 is not “add more confirmations.” The gate already exists; the problem is that it authenticates the message and never the person (no approver allowlist anywhere in the approval path, and the typed path signals the latest open approval with no message binding). F9's own emphasis on least privilege and on making every decision accessible to the user points at the fix: bind the approval to an allowlisted human, and make the audit log readable by someone.
reply.py. ADR 0004's rules 3 and 4 tell the brain to be silent and brief. But the harness posts _WORK_ACK_TEXT (“looking into it… :claude-dancing:”) before the brain runs, and _EMPTY_REPLY_TEXT (“nothing to add there.”) when the brain stays silent — so the workflow authors the narrated silence a policy is forbidding. A policy at the brain layer cannot stop the harness. The fix is an abstain sentinel that DELETEs the ack, plus posting the ack only after first tool use. Until that lands, the ADR describes behaviour the code overrides.AGENT_SIBLING_MAX_HOPS (3) exchanges applied globally, “so a real deliberation thread hits the ceiling long before it concludes. Rule 5 is therefore aspirational until the scoped raise in Deferred lands; until then, deliberation that would exceed 3 hops must collapse into the leader's single consolidated answer instead of silently truncating.” As of the audit, #agents-only held only join messages — no agent-to-agent traffic at all, which is consistent with the cap.SMITH_POLICY.md / CLARA_POLICY.md are operator-installed and never repo-writable; the ADR flags “Operator action required: hand-apply.” The coordination fix is documentation plus a manual step, not something self-enforcing.#agents-only (F5/F6), and no capability scoping to replace the content inspection F6 shows is defeated by prefixing “Additionally.”| Question | Why it is open |
|---|---|
| Does the addressee-handoff result survive the regime change? | The evidence is 4 synchronous agents with a scarce floor and winner-take-all selection. In a 2-agent asynchronous thread where both can post at once and humans participate, the binding constraint may be something the paper never modelled — redundancy and notification noise rather than floor contention. A cheap in-house A/B (handoff-token policy vs threshold-only value gate) on real thread traffic would settle it, since no published work covers this regime. |
| What primitive dedups two near-simultaneous drafts when neither agent has seen the other's unposted draft? | Unstudied. Candidates — a pre-post intent claim (a genuine lock), post-hoc detection with retraction, or a value gate that reads the last N messages including the peer's — each have different failure modes and none is evidenced. |
| In-thread or backchannel deliberation — and what must the audit log record? | The one implemented system routes delegation to a “dedicated session” while describing itself as collaborating in threads, and never evaluates the tradeoff. The in-thread-is-auditable claim was refuted. Concretely: does a human reviewer need to reconstruct why an agent stayed silent (the WAIT-with-required-reason pattern suggests yes), and does that record live in Slack or only in application logs? |
| What replaces permission inheritance for an agent with no invoking user? | Every demonstrated exploit turns on an agent holding broader scope than the attacker under auto-approval, and content filtering was defeated by a one-word prefix. If inheritance from a human principal is undefined for scheduled work, the replacement has to be chosen deliberately. |
Regime mismatch is the dominant caveat. The only quantitative coordination result (F1) is 4 agents, synchronous, one speaker forced per turn, winner-take-all, no humans, murder-mystery TTRPG on GPT-4o/GPT-3.5-turbo. Smith + Clara is 2 agents, asynchronous, threaded, humans present, persistent identity, no scarce floor. The direction is plausible and the mechanism intuitive; the effect size does not transfer, and the paper says nothing about threshold gating, which is what a 2-agent system would actually implement.
The headline metric is LLM-judged. Breakdown labels come from GPT-4 applied to a taxonomy — GPT-4 both generates and judges. The human evaluation (Fleiss κ = 0.77) scored game quality, not breakdown labels. There is no “monopolization” category in the taxonomy, so p<0.001 measures breakdowns in general. One confound: the SS condition also rules that when all agents listen, the previous speaker continues — so consecutive same-speaker turns may partly come from that rule rather than importance comparison.
Material the harness voted down was reinstated, deliberately. F7, F8, F9 and the coverage-matrix half of F4 rest on claims the adversarial pass marked refuted (0-3 and 1-2). The synthesizer re-read the retained primary text and the underlying prescriptions are verbatim present. The refutations were of modal overreach and one bad gloss, not of content: “requires” / “hard confirmation gate” / “any agent action” overstate a source that says “should” and immediately warns about confirmation fatigue; and “validating placeholder messages that are later edited” imported a mechanism the page never describes. Separately, one verifier disclosed exhausting its search budget (200/200), which plausibly caused under-verification of the governance-rubric claims. Treat the refuted pile as containing recoverable material, but keep the corrected phrasing.
Source quality spreads wide. Strong: the turn-taking paper (peer-reviewed, Frontiers in AI 2025) and the security survey (peer-reviewed, ICT Express, cross-mapped to CVE/NIST NVD), plus MITRE ATLAS AML.CS0035. Medium: the governance-gap paper is a 2-author arXiv preprint, presumably not peer-reviewed — upgraded only because its central claims are cheaply-checkable negatives about published specs, which checked out against three current primary specs. Weak: SlackAgents is an EMNLP System Demonstrations paper (lightly reviewed, promotional genre) with zero evaluation, and its most relevant component is unreleased with a design-vs-implementation gap in the shipped code. Vendor-normative, not empirical: both Slack pages — authoritative for platform expectations, no evidence behind any individual prescription, self-declared a “living document.”
Some mappings are inferences we are making, not inheriting. The security survey studies formal protocols (MCP/A2A/ACP/ANP, JSON Agent Cards, registration, task delegation). Whether Slack-mediated natural-language agent chatter counts as a protocol channel in its sense is a judgment the paper never makes. Agent-card poisoning, fake registration and delegation DoS do not map to two identity-parameterised instances of one codebase; only cross-agent prompt-injection propagation transfers cleanly. Likewise the governance paper's five-protocol survey is generalised to “any protocol” by inference.
Threat model without validated mitigations. The survey's own table says of CORBA: “Highlights need for stronger security in LLM-MAS; no concrete defense tested.” Invariant concedes the vulnerability “cannot be resolved through server-side patches. It requires architectural controls.” GitLost defeated deployed vendor guardrails with an “Additionally” prefix within weeks. The corpus tells you what to fear and gives you no evidence-backed defence — capability scoping and least privilege are the reasoned response, not a measured one.
Time sensitivity. Security sources are 1–13 months old in a fast-moving area, and the July 2026 GitLost recurrence confirms both that the injection class is current and that guardrails degrade quickly. The MCP spec revision checked was 2026-07-28 — one day before this research — so the protocol-gap findings are current as of then, and are exactly the kind that a single spec release could change.
Acknowledged coverage gaps, stated as gaps rather than negative findings. (1) Concurrent-draft dedup is essentially unstudied. (2) Ownership locks per se appear in no source; the nearest analogue is the addressee-handoff token, which is a soft convention, not a lock. (3) Backchannel-vs-in-thread deliberation is never evaluated as a tradeoff by anyone. (4) Persona separation on a shared runtime is addressed by no source at all.
Kept in full, because a research page that shows only what passed is not a research page. Several of these were partly recovered into F4, F7, F8 and F9 above with corrected phrasing — the recovery is noted in each finding, and nothing here should be cited in its original form.
| Vote | Claim as originally extracted | Source |
|---|---|---|
| 0-3 | Agent-to-agent messages are ordinary human-readable Slack messages addressed by @mention in the shared thread, not a separate machine protocol; function calling is only the internal layer by which an agent decides to send, so all inter-agent traffic stays human-visible and auditable in-channel. | SlackAgents |
| 1-2 | The post-vs-stay-silent decision for an agent monitoring arbitrary thread traffic is made by the LLM conditioned on a structured system prompt with explicit engagement/silence criteria plus its own tools and capabilities, not by a routing rule or keyword trigger. | SlackAgents |
| 0-3 | A workable implementation of “when should an agent post vs stay silent” is a per-turn think() step that outputs both a binary speak/listen decision and an integer importance score 0-9, with ties broken randomly and the prior speaker retaining the floor if all agents choose listen. | Nonomura & Mori |
| 0-3 | Slack's 2026 orchestration model centralizes multi-agent coordination in a single router (Slackbot) rather than having peer agents negotiate turn-taking directly in-thread. | slack.com/blog agent orchestration |
| 1-2 | Cross-agent task handoffs are modeled as an orchestrator invoking named vendor agents in sequence, i.e. orchestrator-mediated delegation rather than agent-to-agent messaging in the visible thread. | slack.com/blog agent orchestration |
| 0-3 | The paper attributes current inter-agent protocol insecurity specifically to ad-hoc authentication, inconsistent schemas and weak validation, and prescribes dynamic trust management, cryptographic provenance tracking and sandboxed agent interfaces as the mitigations. | Ferrag et al. |
| 0-3 | All four surveyed protocols model multi-agent coordination as directed client-to-remote task delegation in which the human is mediated by a single Client Agent; the comparison dimensions contain no dimension for turn-taking, floor control, or dedup of concurrent agent output in one shared channel. | arXiv 2505.02279 |
| 0-3 | The survey prescribes a four-stage adoption sequence — MCP, then ACP, then A2A, then ANP — meaning a two-agent single-codebase system sits at Stage 1 rather than needing A2A/ANP machinery. | arXiv 2505.02279 |
| 1-2 | Three governance primitives — voting, dissent preservation, human escalation — are Absent in all five protocols; no protocol exceeds 2/12 governance coverage. (Recovered into F4 after verbatim re-verification.) | Kang & Diponegoro |
| 0-3 | No analyzed protocol encodes turn-taking; ACP is the only one with any deliberation support and its negotiation is strictly bilateral. (Recovered into F4.) | Kang & Diponegoro |
| 0-3 | Structured protocols carry coordination payloads but cannot enforce their meaning, so admission, challenge, voting, dissent, escalation and audit semantics get reimplemented per application — and the paper's Listing 1 supplies a concrete missing vocabulary (ADMIT/ROLE, CHALLENGE, VOTE_BLIND, DISSENT_RECORD, ESCALATE, hash-chained audit events) usable as a template. | Kang & Diponegoro |
| 0-3 | Slack's guidance prescribes that agents reply in threads rather than the main channel. (Recovered into F7 — the text is verbatim present.) | Slack agent-design |
| 1-2 | Slack recommends emoji reactions as a first-class “acknowledged, no message needed” channel and prescribes batching related notifications. (Recovered into F7.) | Slack agent-design |
| 0-3 | Slack prescribes an immediate status indicator plus progressive in-place updates, validating placeholder messages that are later edited. Correctly killed — the page describes a status API, plan blocks, task updates and streaming; the message-editing gloss is unsupported. | Slack agent-design |
| 0-3 | Slack requires explicit human confirmation before any agent action with real-world side effects. Correctly killed on modal overreach — see F9's counterweight. | Slack agent-design |
| 1-2 | Slack treats multi-agent coordination and agent-to-agent handoffs as unsettled; the page contains no injection-hardening or A2A/MCP guidance; identity guidance is function-first naming, a distinguishable non-human avatar, and never letting a user wonder if they are talking to a human. (Recovered into F7/F8.) | Slack agent-design |
| 0-3 | Slack's agentic-app guidance sets a hard confirmation gate for real-world output, prescribed as a trust requirement rather than an optional pattern. Correctly killed — see F9. | slack.dev trustworthy agentic apps |
26 sources fetched across 6 angles (multi-agent coordination in shared chat · protocols · Slack-native teammate design · security/hardening · academic failure modes · contrarian practitioner), 4 URL duplicates and 6 budget-dropped. Quality labels are the harness's.