The short answer

Inference control supplies provider-neutral intervention points for cancellation, deny-oriented policy, budgets and model-specific controls. It constrains an invocation through the integrated execution path; it does not make model output authoritative or automatically control unrelated provider calls.

Control the invocation, not just the prompt

A prompt can ask a model to stay within a budget or avoid an action, but the host still needs an execution boundary that decides whether the invocation proceeds. The inference control reference defines provider-neutral points for applying those constraints.

Start by listing how the application invokes models. If one background worker uses the governed runtime and another calls the provider directly, the first path's controls do not automatically cover the second.

Map control intent to provider behavior

Cancellation, deny-oriented policy and budget controls express different decisions. A cancellation request concerns ongoing work; a denial prevents an otherwise proposed continuation; a budget constrains the resources the application is prepared to allocate.

For an illustrative research agent, decide how the provider reports and responds to each supported control. Do not invent a universal token-budget API from this conceptual description. Use the exact adapter contract and verify the behavior of the model integration your deployment actually uses.

Relate interventions to the active session

The Room session documentation distinguishes pre-step, post-output and pre-action checkpoints. A durable intervention is work for a compatible provider, not proof that a model request has already stopped.

Keep the current session and authority context attached to the intervention. The user experience should reflect pending application where appropriate. A provider that can check before the next step may behave differently from one with a request already in flight.

Keep model output below the action boundary

A model can produce a recommendation that survives inference controls and still lacks permission for an external effect. The protected-action layer must independently evaluate the proposed operation.

For example, generating a draft notification and sending it are different actions. Constraining the model's generation does not prove that the delivery connector checked the recipient, payload, approval and current assignment. Review both paths in the integration.

Verify coverage rather than assuming it

  • Inventory provider calls, including retry and recovery paths.
  • Identify which calls pass through the intended controls.
  • Test a denied continuation before provider work proceeds.
  • Observe a cancellation request through its applied or unresolved state.
  • Inspect effect authorization independently from generated output.

The maturity matrix notes that direct calls outside an integration path are not controlled by it. Treat that as a concrete code-review question: show where each relevant invocation enters the boundary and what evidence its handler returns.

Sources and further reading

Documentation reviewed . Consult the linked documentation for current implementation details.