Human in the Loop with Contracts
This is a technical implementation note about the AI assistant architecture in Curling IO v3. It is written for software engineers and others designing agent systems, and goes deeper into Rust, persistence, authorization, and failure handling than our usual product posts.
The usual human-in-the-loop AI agent pattern goes something like this: the model requests a tool call, the agent runtime pauses, a human approves the call, and the runtime resumes so the tool can execute.
That is a reasonable general-purpose design. It is also stricter than simply letting an agent call every tool it can see. For Curling IO, we wanted to expose the smallest possible surface to the model and put an application-owned guardrail around every path to a write. That led us to a stricter question:
If the application already has the exact call details, why hand control back to the agent at all?
By the time we ask a club manager to approve an operation, Curling IO has parsed the model's request, resolved every default, checked the current application state, produced a fixed preview, and stored the exact arguments. The model has nothing useful left to contribute to execution, so we do not let it execute the operation or resume it merely to carry out the approval.
The agent proposes. The application turns that proposal into a contract. The human approves the contract. Rust executes it.