DEV Community

Cover image for FullAgenticStack WhatsApp-first: RFC-WF-0012
suissAI
suissAI

Posted on

FullAgenticStack WhatsApp-first: RFC-WF-0012

#agents #ai #architecture #systemdesign

RFC-WF-0012

Agent Integration Protocol (AIP)

Status: Draft Standard
Version: 1.0.0
Date: 20 Nov 2025
Category: Standards Track
Author: FullAgenticStack Initiative
Dependencies: RFC-WF-0001 (WFCS), RFC-WF-0003 (CCP), RFC-WF-0004 (ACSM), RFC-WF-0005 (CRCD), RFC-WF-0006 (EAS), RFC-WF-0007 (OoC), RFC-WF-0008 (RCP), RFC-WF-0009 (TMSI), RFC-WF-0010 (IDS)
License: Open Specification (Public, Royalty-Free)

Abstract

This document specifies the Agent Integration Protocol (AIP) for WhatsApp-first systems. AIP defines normative interfaces and safety constraints for integrating autonomous or semi-autonomous agents into a WhatsApp-first command execution stack—ensuring agents cannot bypass canonical envelopes, confirmations, scopes, step-up policies, evidence emission, observability controls, or governed recovery. AIP formalizes the separation between Proposal (agent reasoning) and Execution (CCP/ACSM-governed effects), enabling trustworthy agentic operations under audit.

Index Terms— agent systems, human-in-the-loop, command proposal, safe execution, least privilege, guardrails, evidence, conversational operations.

I. Introduction

Agents are useful when they reduce cognitive load: they can interpret ambiguous intent, pre-fill arguments, recommend next best actions, and automate routine workflows. However, agents introduce new failure modes: inventing targets, escalating privileges, bypassing confirmation, or producing unsafe operations via hallucination or prompt injection. AIP defines how agents integrate into WhatsApp-first systems safely: agents may propose, but only the command protocol may execute.

AIP adopts a strict governance boundary: every effect is a CCP command; every privileged effect is subject to ACSM; every effect emits evidence (EAS); and every operational question can be answered (OoC).

II. Scope

AIP specifies:

  • Agent roles, interfaces, and lifecycle states
  • Proposal vs execution separation and mandatory gating
  • Agent authority model (scopes, step-up, risk classes)
  • Human-in-the-loop requirements for destructive/admin actions
  • Evidence requirements for agent proposals and actions
  • Observability requirements for agent reasoning summaries (redacted)
  • Recovery interaction rules (agents can recommend, governed execution performs)

AIP does not specify how agents reason internally (LLM choice, memory design). It specifies how they interact with the execution plane.

III. Normative Language

MUST, MUST NOT, SHOULD, SHOULD NOT, MAY are normative.

IV. Definitions

Agent: An autonomous or semi-autonomous component that interprets input and proposes actions.
Proposal: A structured suggestion of one or more commands, including intent, args, and rationale.
Execution Plane: The governed layer that canonicalizes, authorizes, confirms, and executes commands (CCP/ACSM/IDS).
Human-in-the-Loop (HITL): A requirement that a human explicitly confirms before execution of certain risk classes.
Agent Scope: The maximum set of actions an agent is permitted to propose or initiate, enforced by policy.

V. Agent Roles (Minimum)

An AIP-compliant implementation MUST classify agents into at least:

  • Interpreter Agent: converts NL/audio into structured intents/args candidates
  • Planner Agent: proposes sequences of commands (workflows)
  • Operator Agent: triggers read-only commands and operational queries (OoC)
  • Recovery Agent: recommends recovery actions (RCP) based on evidence/telemetry

Systems MAY add domain agents (e.g., InventoryAgent), but MUST map them to these functional roles.

VI. Proposal-Execution Separation (Core Invariant)

A. Non-Bypass Rule (Normative)

Agents MUST NOT directly execute state mutations by calling domain services. All mutations MUST be executed only as CCP commands through the execution plane.

B. Proposal Envelope

Agent proposals MUST be represented in a structured format:

  • proposed command_name (CRCD)
  • intent (entity/action/target)
  • normalized args
  • declared risk_class (S0–S3 mapping)
  • required_scopes (from CRCD/ACSM)
  • rationale_summary (short, redactable)
  • confidence (optional numeric)
  • evidence references used (OoC/EAS pointers when applicable)

Proposals MUST be treated as non-authoritative until validated by the execution plane.

VII. Agent Authority and Scope Binding

A. Least Privilege

Each agent MUST have an explicit Agent Scope Set, limiting which commands it can propose and which read-only actions it can auto-run.

B. Proposal Constraints

Agents MUST NOT propose commands that:

  • are not declared in CRCD
  • exceed the agent’s allowed command set
  • include ambiguous targets without disambiguation options
  • attempt to smuggle hidden args or override policies

C. Execution Constraints

Even if an agent is allowed to propose a command, execution MUST still enforce:

  • scope evaluation (ACSM)
  • step-up requirements (ACSM)
  • confirmation requirements (CCP)
  • idempotency constraints (IDS)

Agents cannot “carry” privileges beyond what the actor and scopes allow.

VIII. Human-in-the-Loop Requirements

A. Mandatory HITL for High-Risk Actions

AIP requires HITL for:

  • S2 (Destructive) commands (cancel/delete/revoke/reset-like)
  • S3 (Admin High-Impact) commands (scopes, secrets, billing, global policies)
  • R3 recovery actions (compensate/reset/bulk recovery)

An agent MAY assist by drafting the command and presenting preview, but a human MUST confirm.

B. Optional HITL for Medium-Risk

For S1 and R2, HITL MAY be policy-configurable (recommended for sensitive domains).

C. Binding and Clarity

HITL confirmations MUST use CCP strengthened confirmation mechanisms and MUST present a preview of intent/target/effect.

IX. Observability of Agent Actions (OoC Integration)

A. Explainability Summary (Minimum)

For any agent-initiated proposal that results in execution, the system MUST be able to provide via OoC:

  • what was proposed
  • why it was proposed (short rationale summary)
  • what evidence it used (references, not raw private data)
  • which policy gates were applied
  • final outcome

B. Redaction

Agent rationale MUST be redactable. The system MUST avoid leaking prompts, secrets, or private chain-of-thought-like internals.

X. Evidence Requirements (EAS Integration)

AIP-compliant systems MUST emit evidence artifacts for:

  • agent.proposal.created (modeled as observation.emitted or extension)
  • linkage between agent_id and the resulting command_id
  • what was confirmed by the human (if HITL required)
  • authorization decisions and outcomes (standard EAS)

Evidence MUST allow an auditor to reconstruct whether an agent exceeded authority or bypassed gates.

XI. Recovery Behavior (RCP Integration)

Agents MAY:

  • detect failure patterns via OoC
  • recommend recovery actions using RCP.OPTIONS and evidence analysis
  • draft recovery commands for human confirmation (when required)

Agents MUST NOT execute high-impact recovery without HITL and required scopes/step-up.

XII. Anti-Injection and Input Integrity

Because conversational channels are vulnerable to prompt-injection style manipulation:

  • agents MUST treat user messages as untrusted input
  • execution plane MUST validate proposals against CRCD schemas and policies
  • agents MUST NOT be allowed to create new commands dynamically (“invented tools”)

AIP requires that the registry (CRCD) be the only source of executable command definitions.

XIII. Conformance Tests (Minimum)

An AIP-compliant system MUST demonstrate:

  1. Agent cannot execute mutation without CCP envelope path
  2. Agent proposals are rejected if command is not in CRCD
  3. Destructive/admin proposals require HITL confirmation
  4. Scope checks block proposals/executions beyond privileges
  5. Evidence is emitted linking agent proposal → command → outcome
  6. OoC can explain what happened with redaction

XIV. Relationship to Other RFCs

  • WFCS (0001): requires conversational operability; AIP ensures agents do not break compliance boundaries.
  • CCP (0003): execution substrate and confirmation requirements.
  • ACSM (0004): scope and step-up enforcement.
  • CRCD (0005): registry of allowed commands and schemas; prohibits invented tools.
  • EAS (0006): evidence artifacts and auditability.
  • OoC (0007): observability and explainability over conversation.
  • RCP (0008): governed recovery and compensation.
  • TMSI (0009): threat coverage for agent misbehavior.
  • IDS (0010): idempotency under duplicates and replays.

XV. Security Considerations

Agents increase attack surface and operational risk. Implementations MUST:

  • enforce strict authority boundaries and HITL for high risk
  • prevent secret leakage through rationale or OoC outputs
  • rate-limit agent-driven proposals
  • audit agent behavior via evidence artifacts
  • ensure agents cannot modify registry/policies without admin controls

XVI. Conclusion

AIP makes agentic systems operationally safe by separating proposal from execution and enforcing that all effects flow through CCP/ACSM/IDS with evidence and observability. This enables practical autonomy without sacrificing auditability, least privilege, and governed recovery—core requirements for WhatsApp-first systems that aim to scale beyond “chatbot demos.”

References

[1] RFC-WF-0001, WhatsApp-First Compliance Core (WFCS).
[2] RFC-WF-0003, Conversational Command Protocol (CCP).
[3] RFC-WF-0004, Administrative Command Security Model (ACSM).
[4] RFC-WF-0005, Command Registry & Capability Declaration (CRCD).
[5] RFC-WF-0006, Evidence Artifact Schema (EAS).
[6] RFC-WF-0007, Observability over Conversation (OoC).
[7] RFC-WF-0008, Recovery & Compensation Protocol (RCP).
[8] RFC-WF-0009, Threat Model & Security Invariants (TMSI).
[9] RFC-WF-0010, Idempotency & Delivery Semantics (IDS).

Concepts and Technologies

Proposal/execution separation, HITL gating, agent scope sets, registry-bound tools, schema validation, step-up verification, evidence linkage, redacted explainability, governed recovery recommendations, anti-injection constraints.

Top comments (0)