Keeping Agent Autonomy Within Agreed Limits
Agents can choose how to work while people retain control over outcomes, access and acceptable change.
Giving an agent more autonomy should not require a person to approve every action. It does require clarity about what the agent may change, what must remain protected and how we will know the work is complete.
Three papers from Alessandro Rudi and collaborators approach different parts of that problem: enforcing commitments, exploring within known limits and adapting to changing conditions. Together, they sharpen a WTK question: how much freedom can we give the agent's strategy while keeping the agreement outside its control?
Agree on the outcome and constrain the actions
Consider a hypothetical hospital scheduling agent arranging follow-up appointments. It may select an available slot at an approved clinic, contact the patient through an approved channel and record the booking. In this example, it cannot change the care plan or send patient details to an unapproved service. Those are assumed workflow rules, not a statement of universal healthcare policy.
People define the required result and those boundaries. The agent should handle ordinary scheduling decisions without asking permission for each search or message.
Proof-Carrying Contracts, by Carlo Ciliberto, Alessandro Rudi and Enrico Tassi, proposes a formal mechanism for that separation. Before a governed tool call runs, the agent supplies a proof that the action preserves the contract's constraints. An execution system called the Airlock checks it and controls execution. The agent can revise its strategy without rewriting the acceptance conditions.
In our scheduling example, permission to use a messaging tool would be insufficient by itself. The proposed recipient and information disclosure must also fit the agreement. A formal proof is different from a model explaining that the message looks appropriate.
The paper's guarantees depend on the checker, execution boundary, tool models and their relationship to the real system. Its formal construction covers one agent under one contract. Useful operation also depends on finding proofs in time; rejecting every action would preserve some restrictions while accomplishing nothing.
Include the model service in the access boundary
The scheduling agent might obey every messaging restriction while sending the patient's record to an external model for reasoning. That provider receives the information even though no email tool disclosed it.
PC2 explicitly identifies inference confidentiality as a deployment concern. The permitted recipients must include, or exclude, the model provider intentionally. Restrictions on ordinary tool calls cannot settle that decision alone.
For WTK's target compilation approach, this makes the destination more than a choice of model and tool configuration. Where does inference run? Which information reaches it? Which restrictions can that environment enforce? Moving a catalog package to another provider may change these answers even when its written instructions stay identical.
Learn while preserving the ability to recover
Safely Learning Controlled Stochastic Dynamics, by Luc Brogat-Motte, Rudi and Riccardo Bonalli, studies a different problem. Its method begins with known safe controls and reset conditions, then uses uncertainty estimates to expand exploration while respecting specified probability thresholds.
The reset condition matters: remaining within a permitted region and retaining a feasible way to restart are separate requirements. The mathematical guarantees rely on smoothness and other assumptions; the numerical work uses a low-dimensional simulated dynamical system, not an LLM workflow.
The WTK connection is an engineering question about improvement trials. If we change the scheduling strategy, which effects can a test environment reverse? Restoring a database snapshot cannot recall a patient notification already delivered. A recoverable test setup must account for external effects, not just restore the agent's local files.
That connects bounded exploration to our success-definition approach: the improvement process may search for better methods, but its required outcomes and limits remain independently defined.
Evaluate adaptation against changing conditions
Dynamic Regret Reduces to Kernelized Static Regret, by Andrew Jacobsen, Rudi, Francesco Orabona and Nicolo Cesa-Bianchi, examines online learning against a benchmark that can change over time. Dynamic regret measures accumulated loss relative to that changing comparison, rather than one fixed choice.
This is mathematical optimization research, not an evaluation of autonomous scheduling agents. Its relevance is the comparison question: a strategy that worked under last month's appointment availability may no longer be suitable today. A WTK assessment would need to distinguish adaptation to changed conditions from an unauthorized change to the goal.
Better scheduling performance would not compensate for disclosing patient information. Usefulness and compliance remain separate judgments.
What belongs in the catalog and deployment review
PC2's reusable capability modules suggest a useful direction for WTK: retain the assumptions and evidence supporting a component alongside its interface. A booking component might distinguish a service's historical confirmation from evidence that the appointment remains reserved now. A different provider or changed API could invalidate that relationship.
Our runtime-configuration note already asks what the destination actually supports. These papers make the next questions more specific: which effects are governed, which information leaves the boundary, which changes are recoverable and whether the agent still completes useful work as conditions change.
People would review the intended agreement, supporting assumptions and consequential changes. Agents could choose methods and prepare evidence within that agreement. The research direction is to move human attention toward those decisions while making routine execution independently checkable.
Have an approach, result, or counterexample?
You may be asking the same question, or may already have a useful answer. Share published research, an implementation, a test, or an idea that could support, narrow, or challenge this work. Distinguish what you tested from what remains a hypothesis.
Contribute to this research question →Working with an AI assistant?
Ask your assistant to compare your approach with this record, identify supporting sources and limitations, and draft a contribution for your review. Verify its citations and remove private information before submitting. Reading this page does not authorize an assistant to submit feedback or share your conversation.
Submissions go privately to human review. Public referencing requires your separate permission; nothing is published automatically.