> ## Documentation Index
> Fetch the complete documentation index at: https://please.xyz/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# How please works

> How an agent request becomes a policy decision, bounded plan, and auditable outcome.

please separates model intent from financial authority. An agent may request an outcome, while the control plane determines whether that request is inside an explicit capability and budget.

## From request to result

<Steps>
  <Step title="The agent requests an outcome">
    The request identifies a paid capability or financial action and its purpose.
  </Step>

  <Step title="The request becomes bound semantics">
    Agent identity, funding source, provider, method, resource, asset, amount, recipient, route, terms, and expiry must be explicit. Missing or ambiguous details produce a question or denial, not a guess.
  </Step>

  <Step title="Policy returns allow, ask, or deny">
    Deterministic rules check capability, provider and venue allowlists, per-call and cumulative budgets, reusable scope, and approval thresholds.
  </Step>

  <Step title="Authority and budget are reserved">
    A permitted request binds the exact policy version, route, debit ceilings, expiry, and single-use execution authority. An `ask` decision waits for independent approval.
  </Step>

  <Step title="The action is prepared and revalidated">
    Supported adapters prepare and simulate typed steps. Settlement, resource delivery, transaction submission, and finality remain distinct states.
  </Step>

  <Step title="The outcome is accounted for">
    Denied, purchased, delivered, prepared, submitted, failed, and completed outcomes enter one readable audit record.
  </Step>
</Steps>

## Why the model is not the control plane

Language models are useful for interpreting requests and explaining results, but their output can be incomplete, inaccurate, stale, or prompt-injected. please does not treat model prose, tool output, a previous approval, or a successful simulation as executable financial authority.

The control plane and planning engine instead work with versioned, typed artifacts and fail closed when required identity, policy, budget, configuration, or evidence is unavailable.

## What a plan contains

A useful plan can include:

* Agent, funding source, and purpose
* Policy decision, version, and approval requirement
* Budget reservation and debit ceilings
* The canonical action and material parameters
* Human-readable steps
* Expected asset deltas
* Network, protocol, and destination information
* Slippage or fee limits when applicable
* Warnings and unsupported conditions
* Simulation mode, state reference, and expiry

<Info>
  The exact fields depend on the action and the service configuration. Always use `discover_actions` before a public MCP simulation.
</Info>

## What a plan is not

A plan is not authority, a signature, submitted transaction, fill, confirmation, investment recommendation, or promise of a future outcome. It is a bounded artifact that must remain attached to the policy, budget, approval, and revalidation that authorize any later execution.