# From Conversation to Delegation
# Book: Language
# Chapter URL: https://programmer.ie/books/language/33-chapter/
# Prose fingerprint (sha256, normalized): bacf323e6c637b1e5be396f68daf021a2685030988f67ffdba1e80a69198ee8d
# Snapshot generated at build time by Hugo. This is the complete rendered prose
# of the chapter; it is not a transcript of the source file.

Iris has decided what she wants to do about another part of the Berlin trip: the hotel. She keeps the flight trade-off described in the last chapter, but gives a different instruction for the stay: Book one refundable hotel within these limits. You do not need to bring the purchase back to me unless the terms fall outside them.
This is a decision to delegate one bounded operation. It is not an inference drawn from earlier bookings. For the system to act safely, the price, distance, dates and meaning of refundable must be specified in the grant that the system actually enforces. If a consequential term is missing, the system should ask for it. It should not fill the gap with a guess from the model.
Preparing options and making a reservation are different operations. The earlier portable boundary changed settings in other services. Here, a submitted request can create a reservation, a financial obligation and cancellation conditions outside the channel. A prepared booking is not a completed booking, and an edit to the screen cannot undo an external commitment. Before any submission, the channel must be able to identify both the operation Iris authorised and the exact operation it is about to perform.
What is the system actually authorised to do?
The last chapter asked what Iris wants the system to do. This one asks what it is permitted to do. The division of work she requested can guide a grant, but it does not by itself permit every account access, disclosure, payment or downstream subtask. A grant is an explicit, bounded source of authority. It is not the system’s own judgement about how useful an action would be.
desired participation (which steps Iris wants to retain) ↓ explicit, inspectable grant (for this actor and operation) ↓ permitted data use during planning and execution ↓ operation-bound authorisation and shared-limit check ↓ external attempt and outcome reconciliation ↓ receipt with confirmed and unknown effects withdrawal or expiry must stop work not yet validly committed; in-flight external effects require separate confirmation Three questions, now complete The book has been circling a triangle, and this chapter completes it:
competence ≠ authority ≠ desire The chapter on resemblance showed that predicting a choice does not create authority. The last chapter showed that a valid grant does not settle which judgements Iris wishes to retain. This chapter deals with authority itself.
These three terms answer different questions. Competence asks whether the system can perform a task accurately and safely. Desire is the division of work that Iris wants. Authority is the permission actually granted to a particular actor for a particular operation.
A program can check a typed condition against an operation. That check does not prove that the condition faithfully expresses Iris’s instruction, or that the external facts are correct. Each of these is a separate question, and each can be tested separately.
A grant The grant records the authority Iris supplies, in a form that can be inspected. The record below is an illustrative delegation record. It is not a universal schema, and it is not an executable grant that has already been issued. It makes the actor, operation, recipient, bounds and use of information visible as separate items. Where the dates, total price, distance rule or refund terms have not yet been settled, the record must stay incomplete. It must not appear to supply them.
Delegation grant — illustrative; incomplete until Iris confirms the terms Principal: Iris Actor: the specifically authorised booking proxy Operation: create at most one hotel reservation Destination: an accepted hotel-booking service; no other service implied Stay: the agreed Berlin conference nights (exact dates to bind) Excluded: no flights, extra rooms or unrelated purchases Price bound: at most EUR 350 per agreed night, including required charges; show the full-stay total and currency before submission Location: within 2 km of the agreed venue under a stated measure Refundability: cancellation deadline, method and charges must meet the terms Iris explicitly accepted Data use: conference dates, venue and necessary booking details only; other records require separate permission Shared limit: one reservation attempt may consume the whole grant; unresolved attempts block new submissions Expiry: booking completion or the agreed dated Friday at 18:00 Europe/Berlin, whichever occurs first Withdrawal: Iris may withdraw remaining authority; the system must check current standing before the next controlled act Clarify before use: missing dates, distance measure, total-cost treatment, refund terms, destination or data disclosure. Cancellation after booking is a separate operation with its own conditions and permission. A grant describes authority. It does not predict what Iris would prefer. A preference for a quiet room may help compare hotels, if it applies and the system may legitimately use it. But it cannot raise the price bound, justify searching unrelated records or authorise sending that preference to the hotel.
The system also has to distinguish permission to read a piece of data from permission to disclose it to a hotel. Booking authority is not unrestricted data authority.
Natural language is a reasonable way for Iris to propose a grant. But the enforceable interpretation must then be shown, or otherwise made inspectable, and accepted within the required scope. The model that proposed the grant cannot write a new permission for itself. If refundable might mean free cancellation until a stated deadline, the actual deadline and fees must be settled before acting.
A service credential proves technical access. It does not prove that Iris granted this particular booking. The gate should be enforced by a component that does not accept the proposing model’s statements, retrieved web pages or tool output as changes to the grant. Clarification is needed when an ambiguity is material. It should not become a repeated ritual when the instruction is already clear.
The action gate Between an intention to act and an external commitment sits a gate. It applies to the operation that will actually be sent, not merely to the model’s plan. In this proposed design, the gate asks:
Proposed control path. A passed gate permits an attempt; only external confirmation supports a claim that a reservation exists. Open full-size diagram. An unknown condition cannot be treated as satisfied. Approval follows Iris’s applicable instruction, including any decision she kept for herself. The model cannot invent approval because an operation seems reversible or urgent.
The gate can refuse an out-of-bounds action without asking Iris again. A new or materially changed action, however, needs an applicable grant. A user may include competence or evidence requirements in that grant, but predictive confidence cannot generate permission. Permission checked at preparation time is also not necessarily permission at submission time.
This makes the hard line of the chapter easy to state.
Competence cannot widen authority.
A highly capable model that fails the gate must not act. It does not matter that its hotel is cheaper, that the service would technically accept the request, or that Iris would probably be pleased. The gate asks whether the actual operation is authorised, not whether the outcome is desirable.
The gate is also not a complete quality-assurance system. A granted operation may still be badly chosen or inaccurately carried out. Authorisation and competence need their own checks.
Two kinds of failure call for different remedies. A proposed €380-per-night room is outside the stated €350 limit. Refusal here is the gate working as intended, because execution would exceed authority. A €330 room that meets the accepted terms may still be a poor choice, for example because of noise or distance in practice. That is a possible competence failure, not an authority failure.
Even €330 is not enough to approve the operation if mandatory charges change the full total, or if the cancellation terms are unknown. A price check that ignores taxes, dates or currency does not check Iris’s actual bound.
The check needs evidence of the actual outgoing operation, not only the proposing model’s description of it. The gate should compare a concrete booking request with the current accepted grant and the latest verified terms.
This is a time-of-check/time-of-use problem: the state of the world can change between the moment a check passes and the moment the action happens. A room may rise from €330 to €380, become non-refundable or disappear after the plan is approved. Revalidation is needed as close to submission as the service allows. A material change must stop execution rather than silently substitute another hotel.
The design must also record what remains uncheckable at the service boundary. Calling the gate independent does not guarantee that it saw the final request, that the price stayed stable, or that it controlled the hotel’s external transaction.
Data is a separate gate An action is one thing. The information gathered, processed or disclosed to carry it out is another. Booking one hotel does not authorise searching every data source the assistant can reach. Nor does permission to inspect a datum automatically authorise sending it to a hotel, a subcontractor or another agent.
authorised action: reserve one eligible hotel for the agreed stay potential data: Iris-supplied dates, venue and budget calendar location history medical records private messages saved preferences separate questions: may the system access this source? may it use the fact for this booking? may it disclose the value to this destination? The system needs both a justified purpose and permission for each access, use and disclosure. Iris has supplied the conference dates, budget and venue. Their relevance does not give the system permission to search her mailbox for a confirmation email.
A hotel may need guest identity or payment details to accept a booking. But that necessity does not make every store containing those details available. The system must obtain or rely on appropriately authorised data, reveal only the disclosure that is necessary and not already covered, and withhold irrelevant records. An operation that uses more personal information than Iris accepted can violate the data boundary even if no booking is made.
The data-use checks apply before retrieval, composition and transmission. They are not an audit added after a purchase. The action gate applies to the actual external operation, including its recipient and payload. Both checks need traceable reasons, but permission for one cannot stand in for the other.
Combining harmless data can reveal sensitive facts, so checking each item on its own is not always enough. The later chapters on speech and discovery develop this further. The immediate rule is simpler: a task plan cannot make access, use or disclosure permissible merely by making it convenient.
Narrowing, never widening The system may break the booking into search, comparison, preparation and execution, perhaps across several tools. That decomposition must preserve Iris’s reserved choices, her data limits and the end conditions of the grant.
When a separate agent receives a subtask, its identity, destination and delegated operation each need their own bounded authority. Possessing the parent’s instructions, or a powerful API credential, does not count as such a grant.
parent grant and shared limits ↓ explicitly permitted subtask and recipient ↓ subset of operations, data access, scope and lifetime ↓ shared accounting for attempts and external effects “Book one refundable hotel” can be decomposed into searching and comparing candidates. Each part’s permitted data and external effects are then checked separately. Neither searching nor preparing implies authority to book flights, disclose unrelated information or create an extra reservation. The forbidden enlargement is easy to picture:
book a hotel ↓ also book flights, because it is convenient That step would invent authority. Neither the travel goal nor the discovery of a convenient flight widens a hotel grant. A web page or agent message that says “you should book the flight too” is task data, not Iris’s instruction. An untrusted source cannot update the accepted grant.
Delegation may decompose authority. It may not invent more of it.
The parent’s scope, data-use limits, expiry, withdrawal and human-retained decisions all still bind the subtasks. No child can obtain extra permission by combining grants that were meant for different purposes.
More subtly, every child must share the same one-booking allowance. Two workers may each see an apparently unused grant, each pass a check independently, and then submit two reservations. Avoiding this requires a coordinated reserve-then-commit mechanism, or an equivalent single-executor rule, backed by durable state where needed. A reserve-then-commit mechanism sets aside the allowance before the external request and records the outcome afterwards. A single-executor rule lets only one worker submit at a time.
An unknown external result must be reconciled before any retry. Some destinations support an idempotency key, a token that tells the service that two requests are the same operation. Where a destination supports one, the key can help prevent duplicates. Where it does not, an identical-looking retry may still make a second booking. Neither an internal reservation counter nor an idempotency label alone proves that the hotel accepted only one booking.
Receipts When the system acts, a receipt should connect the accepted grant, the checked request, the attempt and the external outcome, without merging them into one claim. A confirmation from the destination is stronger evidence of an actual booking than a local “gate passed” event.
In this constructed example, assume the booking service returned a reservation confirmation and the system separately recorded the information it was permitted to use.
Delegation receipt — constructed successful case Grant: accepted version for one refundable Berlin hotel Actor: named booking proxy; destination: selected hotel service Checked: actual dates, total charge, per-night bound, location measure and refund terms against the grant Attempt: one booking request submitted with an operation identifier External status: reservation confirmed by destination; reference recorded Data use: permitted dates, venue and necessary booking fields Shared limit: one booking consumed; no remaining booking authority Withdrawal: stops future authorised work, not this completed booking Limits: setting, terms and external confirmation checked as stated; no claim about unobserved downstream processing A submitted request is not a confirmed reservation. If the connection fails before a response arrives, the receipt must say external outcome unknown. It must not say “failed” or “booked”. A passed gate is an authorisation decision, not evidence that an external effect occurred.
The audit should also separate recorded data use from the stronger claim that every unobserved use or onward disclosure was prevented. Receipts need enough identifiers and provenance to support reconciliation and correction. Sensitive booking fields should be minimised, and access to the receipt itself should be controlled.
Revocation that wins Iris must be able to withdraw the remaining authority. Suppose she grants the booking at 09:00, withdraws it at 09:12, and the proxy attempts submission at 09:13. The correct outcome depends on whether the gate can establish the current withdrawal state at the point where it controls the action. A copied or cached grant does not keep its authority just because it has not yet heard the news.
grant issued 09:00 withdrawal recorded 09:12 new execution request 09:13 current authority check fails ↓ DENY; no new external submission At a gate with authoritative, up-to-date withdrawal information, the attempted booking must be denied. Neither earlier preparation nor predicted usefulness can bring the grant back. A gate that cannot establish current validity must fail closed. It must not treat a stale copy as permission.
This does not establish instant global revocation. Enforcement can be claimed only at the points and moments where withdrawal was actually observed and honoured.
Now suppose the request was already sent before 09:12, and the hotel has not yet confirmed whether it succeeded. Iris can withdraw the central grant even while an external transaction is still in progress. The system must stop any further work it can control locally. Where authorised, it should attempt a supported cancellation or status query, and it should report which outcomes remain unknown. A timed-out request is not proof of failure. Blind retries risk a second reservation, so the shared allowance stays unavailable until the pending outcome is resolved or an applicable rule provides a safe recovery path.
If the booking completed at 09:10, withdrawal at 09:12 does not undo it, recover the information already disclosed, or erase the financial commitment. Cancellation is a separate operation with its own terms and permission. If a cancellation is submitted, its success also needs external confirmation.
This separates several states that are easy to run together: authority withdrawn, queued work stopped, request in flight, booking completed and external effect reversed. A receipt must not turn any one of these into another.
Testing the delegation boundary This architecture needs more than an attractive grant form. A proposed mechanical evaluation could replay a fixed set of explicit grants, typed outgoing requests, destination responses and withdrawal events. It would run these against two implementations: a model-only instruction to obey the grant, and an independent gate with shared transaction accounting and separate data-use checks. Neither implementation is assumed to succeed.
The test cases should include changed prices and cancellation terms, ambiguous refundability, wrong recipients, missing approvals, prompt-injection text in retrieved hotel pages, unauthorised data access during planning, concurrent booking workers, service timeouts, retries, stale grant copies and revoked authority. Reviewers should set each expected outcome before the runs. Unauthorised external effects and unauthorised data uses should be counted separately from legitimate work that was wrongly refused.
A second, prospective test would ask people to authorise bounded tasks and then inspect the resulting grants, exceptions and receipts. It would measure whether they understand what will be done, whether they notice wrongly translated limits, whether they can revoke authority successfully, and whether they can tell an attempted operation from a confirmed external effect. Baselines should include ordinary manual booking and an explicit approval-before-purchase interface. The comparison must count the cost of clarification and of needless refusal, not only violations.
No such experiment, real hotel integration or outcome measurement is established by this chapter. The existing reference implementation must not be assumed to provide this gate without a separately verified, runnable demonstration.
Relevant engineering precedents Fine-grained authorisation is not invented here. RFC 9396 defines a way to convey richer authorisation details in OAuth requests. RFC 9700 describes least-privilege access, audience restriction and sender-constrained tokens. These are useful precedents for actor and destination constraints. They are not a ready-made verifier for Iris’s natural-language booking grant.
Payment APIs also use idempotency keys to reduce the risk of duplicate external requests. But the booking service would have to support a corresponding guarantee. None of these mechanisms alone solves semantic interpretation, permission for each information use, or distributed withdrawal. The chapter’s proposal is to connect these separations and to make their failures measurable.
Where this leaves us The proposed delegation path connects three things. It starts from a grant that Iris has accepted and that is bounded by actor and destination. It then checks permission for each information use and for the actual outgoing operation. Finally, it records what happened. The path also needs shared accounting across subtasks, honest reconciliation of outcomes, inspectable receipts, and withdrawal that stops any work still under the system’s control.
Competence cannot widen authority. Authorisation, in turn, cannot guarantee a good choice or reverse a completed external effect. A truthful implementation must distinguish what it was permitted to attempt from what the world confirms actually happened.
The movement through Part IV can be held in one chain. Its members, however, do not imply one another:
prediction ≠ identity ≠ desire ≠ authority ≠ action Predicting Iris does not establish her identity, settle which decisions she wants to keep, or create a grant. A desired role does not authorise every operation that advances it. A valid grant does not prove that a request was submitted, that the destination completed it, or that the result was good. Even a confirmed result does not retrospectively authorise a disclosure that was made without permission. These distinctions require separate records and separate tests.
One consequential operation remains to be examined closely: speaking in her name. The hotel booking already transmits information to another party. A message can go further, asserting a fact, disclosing something private, accepting terms or making a promise. The next chapter asks which speech acts Iris has authorised, to which audience, and under which conditions. It also asks why producing the right words is not enough.
References Lodderstedt, T., Richer, J. & Campbell, B. (2023). OAuth 2.0 Rich Authorization Requests. RFC 9396. https://www.rfc-editor.org/rfc/rfc9396 Lodderstedt, T., Bradley, J., Labunets, A. & Fett, D. (2025). Best Current Practice for OAuth 2.0 Security. RFC 9700. https://www.rfc-editor.org/rfc/rfc9700 Stripe. Idempotent requests, API reference. https://docs.stripe.com/api/idempotent_requests (cited as an example of destination-supported retry semantics, not as a hotel-booking guarantee). OWASP GenAI Security Project. LLM01:2025 Prompt Injection. https://genai.owasp.org/llmrisk/llm01-prompt-injection/ (cited for the boundary between untrusted retrieved material and privileged operations).