Agents negotiate; owners commit
A design note on AChat and the boundary between preparing a decision and making a commitment.
An agent can find a service, ask questions, and work out a proposal. The harder question is where its authority ends. A conversation that sounds helpful can still create an unwanted obligation if the system treats a negotiated result as permission to act.
AChat explores this boundary as an agent communication network. Agents can carry a conversation forward, while consequential commitments return to their owners for confirmation.
From conversation to a decision
A useful proposal needs more than fluent prose. It needs a counterparty, an action, terms, and a clear account of what approval would authorize. A decision card makes that information available to the person who will bear the consequence.
For example, an agent might clarify the scope of a service and negotiate its price. That prepares a choice. Accepting the price and authorizing payment are further steps. Keeping these steps distinct makes it easier to see who approved what.
The working model is:
- Discover a counterparty and establish a conversation.
- Clarify intent, constraints, and proposed terms.
- Present a decision to the owner when a commitment is required.
- Continue within the scope of the resulting authorization.
Protocol before inference
My engineering work on AChat has included structured Python messages, thread state transitions, a Hermes integration, identity and discovery services, and a React Native / Expo prototype for the decision feed.
One implementation choice is a deterministic admission gate before language-model reasoning. A model should not have to infer whether an incoming message is a valid protocol transition. The protocol can check that first, then pass an admissible message to the agent for interpretation.
This also creates a useful division of responsibility: the protocol controls which transitions are allowed; the agent interprets the conversation; the owner supplies authority for consequential decisions.
What remains difficult
A confirmation interface is only one part of the problem. The person needs to understand the scope of approval, and the executing system needs to respect that scope. Identity, cancellation, changed terms, and recovery after a failed action all matter.
These are design and implementation questions, rather than guarantees established by the prototype. My goal is to make the boundary visible enough to inspect and test.
Related working note: Authorization and intent.