IntentChain Business Agent

Inspiration A ten-person company has no travel desk and no procurement team. AI agents could do that work, but no owner hands an AI the company's money.

Expense policies — allowed categories, budgets, approval limits — check one thing: is this purchase allowed? Agents do not work alone, though. One agent breaks a job down and hands pieces to other agents, which hand pieces on again. We kept running into the same uncomfortable case: a purchase that is an allowed category, within budget and within authority, and still not what the employee was sent to do, because the task changed shape somewhere along the way. Nothing in a policy catches that.

What it does For the owner. Set a spending policy once: what agents may buy, a trip budget, and an auto-pay limit. Connect PayPal once.

For the team. Ask in one sentence: "Sean is travelling to Tokyo for a client meeting next week. Arrange his hotel and eSIM." Agents arrange it and pay.

Three outcomes for every purchase an agent proposes:

Auto-pay — passes all five checks and is under the owner's limit. Captured at once with the PayPal account the company saved in the PayPal Vault, with nobody in the loop. Manager approval — passes all five checks but is over the limit. A manager approves it in PayPal. Blocked — any check fails. Nothing reaches PayPal, and the firewall names the agent, or the delegation hop, responsible. Five independent checks: company Policy, Budget, Authority, Scope, and Intent. The first four are what an expense policy can do. The fifth is what makes this different.

What an expense policy cannot do:

Authority can only shrink. Every grant from one agent to the next must be a subset of its parent — amount, place, dates, categories, lifetime. Ask for one extra capability with the same amount and the grant is rejected. The chain is signed. Each grant is signed over its parent's signature. An altered or invented grant does not verify. PayPal permissions shrink with it. The Hotel Agent can search but holds no PayPal tools at all. The Recovery Agent can refund but cannot pay. Intent drift is measured at every hop. When the Travel Agent hands off "improve the overall travel experience", that grant is structurally valid — and its intent fidelity drops. The agent that receives it books a sunset dinner cruise as a business meal. Allowed category. In budget. Within authority. Every policy check passes. IntentChain blocks it and traces it to the exact hand-off where the task drifted. Payment is not the finish line. If the hotel cancels after a successful payment, the transaction is marked outcome failed, refunded through PayPal, and a replacement is proposed for approval. The same policy and firewall handle a short office purchase: adapters for new hires are auto-paid, a gaming graphics card is blocked.

How we built it PayPal Agent Toolkit (@paypal/agent-toolkit) in the sandbox: create_order, get_order, pay_order for manager-approved payments, create_refund for failed outcomes, get_order and get_refund for reconciliation. Each agent role gets its own toolkit instance configured with only the actions it was granted, so PayPal permissions narrow along the delegation chain exactly as spending authority does. PayPal Vault (payment method tokens v3) for auto-pay: the owner saves the company's PayPal account once; orders under the limit are created and captured in a single Orders API call against that payment token, with the transaction id as the idempotency key. PayPal Webhooks: each delivery is verified with PayPal before it updates a transaction. Lineage in the PayPal record: the intent id, agent and transaction id are written into every order's line item, so PayPal's own record links back to the request. JEV (TypeSafe System One) for intent analysis: classifying the request, scoring each purchase's alignment with it on a five-level rubric, and scoring how faithfully each delegated task stays within the original request. The AI can block or escalate; it can never approve a payment by itself. Signed delegation chain: HMAC over each grant's limits plus its parent's signature, re-verified top-down before every transaction. Agents that plan for themselves: given a tool-calling LLM (Claude, through an OpenAI-compatible endpoint), an agent reads its delegated task, the company policy and an instruction, searches the catalogue and calls the PayPal tools itself. In the demo the model, knowing entertainment is blocked, picks a dinner cruise as an allowed "business meal" — and is blocked on intent drift. It never has PayPal access of its own. Agent gateway: any outside agent can act under a signed grant token, sees only the tools that grant carries, and meets the same firewall. An example Claude agent is included. Channel3 for live product search: for office purchases the Sourcing Agent searches real retailers, records which match it chose and why, and the Purchasing Agent pays for that product. AG Grid for the company ledger: every proposed purchase with the verdict on each check, per-column sort and filter, quick search, a pinned totals row and CSV export. Next.js + TypeScript + SQLite, one process. Each browser session gets isolated state. Challenges we ran into Making "auto-pay" true. The normal checkout needs a buyer to log in for every order, which makes "auto-pay" a lie. We use the PayPal Vault: the owner saves the company's PayPal account once (setup token → approval → payment token), and every purchase under the limit is then created and captured in one Orders API call with no buyer present. Keeping the checks from overlapping. Early on, "what is being bought" leaked into Scope, which meant the interesting case was blocked by a plain rule. We narrowed Scope to where and when, moved "what kind of thing" to company Policy, and left Intent to answer only "is this what was asked for". An AI that scores but must not decide. The intent model returns a rubric score. We made it impossible for that score to approve a payment on its own, and removed the benefit of the doubt for purchases that arrive through a drifted hand-off. Not charging twice. Order creation, capture and refund are never retried automatically; capture reads the order first; auto-pay uses an idempotency key. Accomplishments that we're proud of A purchase that passes every policy check and is still correctly blocked — with the responsible hand-off named. Real PayPal sandbox flows end to end: auto-pay, manager-approved checkout, refund, reconciliation, verified webhooks. A real LLM agent that reasons its way around the policy, and is still caught. 56 automated end-to-end checks that run against the live demo. A firewall other people's agents can use, through a signed grant token. What we learned Limiting how much an agent can spend is the easy half. The hard half is that authority and purpose both change as work moves between agents, and they change in different ways: authority can be checked with set arithmetic, purpose cannot. You need both, at every hop.

What's next Every agent planning with an LLM end to end; today the drift step and free-form instructions do. Each agent holding its own signing key, so the chain is verifiable across organizations. More PayPal surface: invoices for vendor payments, payouts for reimbursements, dispute handling in recovery. Live hotel and travel search in place of the fixed travel catalogue (office purchases already use live product search).