A WhatsApp Capability Should Capture, Not Execute

A contact asks a WhatsApp agent for an appointment. The dangerous interpretation is: the agent now has permission to book one. APX uses a narrower interpretation: the agent may capture the request for its owner to confirm.

That difference keeps a conversational convenience from quietly becoming an execution path.

APC is the portable context layer. It keeps durable project material in the repository: AGENTS.md, .apc/, agent definitions, skills, commands, and MCP hints. APX is the daily-use runtime and tooling layer. It handles local channels, runtime state, identity, and the live decisions around an inbound message.

A WhatsApp request is runtime work. It should not turn into a portable project instruction—or an automatic external action.

Capabilities are deliberately small

APX's WhatsApp configuration recognizes three capabilities: appointments, errands, and facts. All start off by default.

The names can be misleading if read too quickly. They are not tool grants. A non-owner WhatsApp turn has no tools. Enabling appointments or errands lets APX extract a request into a pending suggestion; it does not let the conversation book, send, promise, or decide anything.

The split matters because answering someone and acting for them are different kinds of authority. A natural reply can say, “I’ll pass that along for confirmation.” It must not say a time is agreed, a slot is free, or an errand will happen.

facts is the other deliberate boundary. When an owner has written approved facts for a contact, APX may answer from those facts. Anything outside them remains unknown. A friendly contact-specific rule can adjust tone, but it cannot create facts or tools that the runtime did not supply.

Capture runs beside the reply

For enabled appointment or errand capture, APX reads the inbound message separately and records a structured pending suggestion. It preserves the sender, request summary, requested work, urgency, and the sender's timing words.

That last detail is important. If somebody says “tomorrow afternoon,” APX stores those words rather than resolving them into a timestamp. The capture layer is not allowed to make a calendar decision merely because it understood the phrase.

APX also keeps capture separate from the reply text. Hiding machine-readable request data inside a reply would require stripping it before delivery. A failed strip could expose internal machinery to the contact. With a separate capture pass, the reply stays plain text and a capture failure only loses a suggestion; it does not corrupt the conversation.

A practical flow

Imagine a plumber writes:

Can I come by tomorrow afternoon to check the leak?

With appointment capture enabled, APX can create a pending request containing the contact, purpose, and exact timing language. The owner receives something to review. The agent's reply can acknowledge the request and say it will be passed on.

It cannot confirm the visit. It cannot claim the owner is available. It cannot turn “tomorrow afternoon” into a booking.

This is less flashy than an agent that acts immediately, but it is more truthful. The system knows it has captured intent, not completed the work.

Why APC stays out of it

The project may travel between repositories, machines, and compatible tools. WhatsApp contacts, owner approval, pending requests, and channel-specific capabilities should not travel with it as committed project truth. They depend on a particular account, operator, and moment.

So APC describes what the project is. APX handles what a local messaging surface may safely do today.

The useful rule is simple: when a message asks for real-world action, first capture intent. Then let a responsible human—or an explicitly authorized execution path—confirm the action.

A channel capability should make a request visible. It should not silently make that request true.