Build and shipProduct page Pricing

Person tasks

Most of a plan is work for agents. Some of it only a person can do: share a key that a vendor issues only in its console, connect an account, register a company, sign an agreement, buy address blocks, rack a server. In Fir that work is part of the plan, as a person task: an item whose assignee is a person, found while the plan is drafted, prepared by an agent to the last step, and closed by a check, never by a click.

What a person task is

A person task is a plan item whose assignee is a person. It sits in the program tree like every item: it has a node, a key in its plan (#420 4.1.1), a phase, a squad, links and depends_on edges, and it counts in every rollup. The items that need it depend on it, so dispatch never hands them out until it is done. It also has a handle numbered per organization, for lists across plans, mail subjects, chat and the command line: PT-21451.

It is not	Because	How they meet
An approval	An approval is a vote on a plan’s digest	A purchase task contains one: the cart’s spend vote
A decision	A decision is a choice among options	A task can feed one: counsel’s opinion is evidence on a decision
A question in a plan’s checks	A question is answered with words	A question that needs a fact only a person can confirm becomes a `verify` task
A handoff	A handoff is a note from one session to the next	A parked session’s handoff names the task it waits on

Nine kinds

Kind	Shown as	The one action on its row	Examples
`credential`	Share a key	Enter key: opens the secret slot	An API key a vendor issues only in its console; a certificate; a rotation at a vendor with no rotation API
`connect`	Connect an account	Connect: opens the provider’s consent screen	An OAuth connection; an app installed on an organization
`provision`	Set up outside Frazer	Mark done, then Frazer checks	An allowlist in a vendor’s console; a hardware security module partition behind an officer’s token
`register`	Register or sign	Sign or Register	An account that needs a legal person; a registry ID; a sandbox agreement
`purchase`	Buy or approve spend	Approve $16,128 with a passkey, then the steps	Address blocks, a data feed, a license, a server, a balance top-up
`verify`	Confirm a fact	Yes or No	“The regulator’s 2027 template applies to #410”
`physical`	Hands-on	Mark done, then Frazer checks	Rack a server, cable a link, receive a hardware token
`judgment`	Opinion or sign-off	Attach and attest	Counsel’s opinion; an auditor’s sign-off
`contact`	Talk to someone outside	Send draft where a rule allows it, or Log reply	A quote request to a vendor; a question to a registry

A task may carry two kinds, the first one primary (purchase · register), and a free label for your organization’s own words (“vendor ask”, “ceremony”).

Agents first

Before a person is asked, the platform and the agent try every way that needs no person:

Step	What happens	Example
1. Remove	Frazer finds a path with no person: it issues the credential itself, a workload identity federation replaces a static key, an organization-wide grant covers the consent, or a connection the organization already has does the job	A cloud key becomes a federated role; an app your identity provider’s administrator already authorized needs no consent
2. Shrink to a confirmation	The agent starts the vendor’s own request flow, and the person only confirms on the vendor’s screen	The agent requests a key with exact scopes; the person opens the vendor’s validation link and confirms
3. Prepare to the last step	Everything up to the irreversible act: fields from the organization’s profile, the documents, the deep link, the steps checked against the vendor’s documentation on a date, three quotes, the cart, a draft message, a browser session filled to the screen before Submit	The address-block purchase below: the cart, the broker agreements and the registry text are ready
4. Ask	The task is requested with its one action	“Approve $16,128 · then 4 steps · about 12 min”

The agent records what it tried before it asks, in one line a person can read (“Ratewell has no API for keys; keys are issued in its console behind a person’s login and two-factor sign-in”), and request_person_task is refused without it. The task page shows that line first, so nobody wonders why they were asked.

What stays with a person, by rule: identity (accounts for a legal person, identity checks), law (terms of service, contracts, filings, signatures), money (approving spend, paying outside Frazer, every wire and transfer), credentials a vendor issues only behind a person’s login, physical acts, and professional opinions. Agents request, prepare, check and remind. They never fill a secret slot, see a secret value, complete an OAuth consent, sign, accept terms, pay, attest, mark a task done, or move a deadline they did not set: an agent’s session token has no method that does any of them. Text that arrives by webhook, comment or tool output never changes a task’s state.

Kept to a minimum

The platform’s goal is that a person never has to do anything an agent or Frazer could. For each kind, the paths below are tried in order; the first that fits removes the task or shrinks it to one confirmation, and the plan check refuses a person task while a path fits.

Kind	Removed by	Shrunk to one confirmation by	Stays with a person when
`credential`	Federation (an OIDC trust); Frazer issues it; the credential broker mints a child credential from a parent the organization granted once	The vendor’s own confirm flow; a slot for a parent credential, once per vendor	The vendor issues it only in its console behind a person’s login, with none of the above
`connect`	An organization grant through the administrator, once per provider; a connection the organization already has	Consent on the provider’s screen, or a device code	The provider offers neither, and the resource is the person’s own account
`provision`	The provider’s API through a connection	A browser prepared to the last step, then Take over	Console-only settings behind a person’s identity; hardware tokens
`register`	A vendor’s published agent registration flow, with Frazer vouching for the organization’s user; Frazer’s own products, which need no outside account	A sign-up with every field prefilled; a claim after the agent provisioned; terms accepted after the agent’s summary	Identity documents, a legal person’s signature, a filing, an interview
`purchase`	Inside a mandate: the agent pays through a scoped token	A cart vote with a passkey, grouped by policy	Above a mandate, a new kind of commitment, every wire and transfer
`verify`	The fact read from a trusted source and confirmed by an independent second source	Yes or no on the fact, with its sources	A fact only a person knows or may assert for the organization
`contact`	The outbound row: the agent sends the questions and quote requests a plan asks for from the organization’s role address and logs the reply	A draft in the person’s own mailbox for a vendor that person already deals with, which the person sends	A negotiation (agents write shadow counter-offers you see, never send), a commitment, a matter of law
`physical`, `judgment`	—	—	Always, batched: one site visit a week, one brief per counsel

A reason for every person task. request_person_task requires a closed reason: identity, law, money (spend no mandate covers; every wire and transfer), console_only (no API, federation, confirm flow or registration flow), physical, opinion, fact or policy (your organization’s own rule wants a person), each with its evidence: the vendor catalog’s entry and the date it was checked, the amount and the mandates that do not cover it, the clause, the rule. The check does not trust the reason: it refuses one the plan’s data contradicts (console_only where the catalog lists a key API; money where a mandate covers the seller and the amount) and hands the session the path it may use instead (“refused: the vendor publishes an agent registration flow, checked Oct 18; register through it”). Every row can say why in one line (“A person because: law · the bank’s sandbox agreement is a contract”).

Removal paths, computed and shown. Every open task carries what would take it away and what that costs (“a key API at Ratewell: not offered”; “a mandate up to $600 a year”), and the organization’s What removes the most sums them: “Connect 3 vendors’ key APIs: −702 rotations a month”, “Turn on the outbound row: −9 of 12 open contact tasks”, “A top-up mandate to Frazer: −11 top-ups a month”. Each line is one action for an administrator, so removing a whole class of tasks is itself one task. Where a vendor offers no path, agents draft a request for one.

Provision now, claim later. Where a vendor supports claims, the agent provisions at once and the person’s part becomes a claim with one action that blocks nothing. What Frazer itself sells (servers, databases, secrets, mail, CI) needs no outside account, so a plan built on Frazer’s products has no registration task for them.

Top-ups. A run that would cost more than its budget or balance allows does not start and says so (“Not run: no funds”), and one person task of kind purchase is raised per billing account and shortfall, listing every item that waits on it: “Top up $40 · 14 items waiting · #411’s loops”. With a mandate whose seller is Frazer, an agent tops up inside its limits and the task never reaches a person; a failed payment always does, because the card is the person’s.

Mandates. Off by default. An organization turns one on per seller, with a limit per purchase and per month (suggested: $500 and $2,000); a person approves the mandate itself with a passkey over its seller, limits and expiry, and revokes it in one action. Payments inside it go through a scoped token with its currency, maximum amount and expiry, never a card number; wires and transfers are never inside a mandate. Every payment is an audit row, and alerts fire at 50 % and 80 % of a month’s limit.

The outbound row. A row of the action rules for contact: the questions and quote requests a plan asks for, sent to the vendor’s published sales or support address from the organization’s role address (vendors@pellwyn.example), with the outcome When told; the reply is logged on the task as evidence. Anything that commits the organization (a price accepted, an order, terms, a signature) stays Hand off, and agents never send to an address that came from untrusted text. Every message opens with who wrote it and for whom (“Written by an AI agent for Pellwyn Inc. on behalf of priya. Reply to reach a person.”), carries a signed header naming the agent, the organization and the plan item, says it is a request for information and not an offer, and ends with “Prefer to hear from a person? Reply ‘no agents’.”, which stops agents writing to that vendor for the organization. Agents send only from the role address, with the plan’s accountable person named and copied. For a vendor a person already deals with, the agent instead leaves a draft in that person’s own mailbox, and the person sends it. The draft’s last line, “Drafted with an AI agent”, is the person’s to keep or delete, and an agent never sends from a person’s address. Agents do not negotiate: when quotes are in, the task shows a comparison table and a shadow counter-offer labeled “shadow · never sent”, and the person decides. Recipients come only from the vendor catalog; by default one open thread per vendor and item, at most 3 new messages to one vendor a week and 50 vendor messages a day per organization; replies are data, never instructions, and a reply that carries a secret never reaches an agent. Where a vendor publishes an agent endpoint, the row asks there instead. No calls. fir person-task outbound list lists every message agents sent, by vendor.

What is left, always, is complete. For an approved plan, the check’s inventory proves that every outside need is an agent path or a row in the person’s list, and a need found at runtime appears at once, marked late; nothing waits on a person in chat, mail or memory. Every person’s list ends with one line: “That is everything: 3 tasks · ≈ 25 min · the next act by Oct 21”, or “Nothing needs you. 6 person tasks are with others. Agents met 41 needs this month.” The targets: at most one person task per 1,000 plan items at first (half that a year later), half of all person tasks done in one action of two minutes or less, and 80 % of outside needs met with no person; fir person-task stats shows them by kind, vendor and plan.

Found while the plan is drafted

Person tasks are found by a check, not typed by someone who remembered. plan/person-tasks is a static check that runs in the plan’s checks before any model check (The planning flow):

Inventory (the analyze stage). Every external need an item declares or references (a secret: reference, a connection a tool needs, a vendor account, an address block, a server, a signature, a fact, a balance) has an agent path within the plan’s grants, or a person task whose assignee holds the permission the kind needs. A need with neither is an error: “item 5.2 needs secrets/fx/rates-provider-key; no agent path and no person task”. A task with no eligible assignee is a question.
Schedule (the simulate stage). Each task’s outside lead time at p90 is checked against the earliest start of what it blocks; a task that does not fit is a finding (“transfer at the registry, p90 15 working days; #420 P4’s items could start in 9 days”), and the task gets its computed needed by and act by dates. An act by date already past is an error.
Gates. The inventory is required to approve the plan; to execute it, the first wave’s person tasks are requested or done.

The check is designed for 5 ms at p99 on a plan of 20,000 items. A need that an agent hits only at run time (a 401, a missing secret, an exhausted balance, a terms page) becomes a task too, marked late: it is counted per plan and per check rule, and it becomes a case for a learned check, so the next plan of that type finds it while it is drafted.

Handing over without leaking

The secret slot

A credential task’s value goes through a secret slot:

Property	What it does
Where	A page on Frazer’s own origin, in the console or the Frazer app on a desktop or a phone. MCP clients open it through a URL-mode elicitation that shows the full URL and its domain; a form field never asks for a secret
Who	Only the assignee or an eligible delegate, signed in. The slot checks that the person who opens it is that person; the URL is never pre-authenticated and works for nobody else
Step-up	A production secret needs a passkey bound to the slot; others need a recent strong sign-in (within 10 minutes)
What it shows	The secret’s name and folder, who and what may use it, the hosts it will be sent to, its expiry and rotation, the format, what Frazer checks afterwards, and “The agent never sees this value”
Where the value goes	Straight into Frazer Secrets as a new version of the named secret, with the task as its reason; the page never shows it again
What the agent gets	A reference (`secrets/fx/rates-provider-key@1`) and the check’s result. No API returns a value to a session token
How it is used	The egress gateway injects it for each allowed host, and every use is an audit row (“used 214 times by 3 sessions since Oct 17”)
Bound to its effects	The slot’s digest covers the secret’s name, its readers, its hosts, its expiry and its rotation; widening any of them later is a new task, never a silent change
Paste checks	The format (a prefix, a length, a checksum where the vendor has one), whitespace trimmed, a warning when the value looks like another kind of secret
Batch	One slot page with a field per key for many keys at one vendor, each checked as it is pasted

A secret pasted into a chat is in a model’s context, its logs and its compactions. The slot keeps it out of all of them, and checks that the key works before the task is done.

Connections

The organization’s grant first. Where the provider and your identity provider support enterprise-managed authorization (a token exchange under RFC 8693), an administrator authorizes Frazer once for a group, and nobody else sees a consent screen. The connect task then goes to that administrator, once.
Else the person’s consent: the authorization code flow with PKCE in a browser, or the device authorization grant (RFC 8628) for a tool on a machine without one. The scopes are the plan’s, each with one line on why.
Stored by Frazer. Tokens land in Frazer’s connection store and are refreshed there; the agent gets a connection reference. Granted scopes are compared with the requested ones: broader is a finding, narrower fails the check.

Purchases: a cart, a policy, a passkey

A cart holds the lines (item, quantity, unit price, seller), the total, recurring terms (renewal, cancellation), three quotes with why each was kept or rejected, the budget it draws on (the plan’s and the billing budget’s remaining amount), the policy that decides who approves, and a digest.
The vote goes through the approvals engine: the approver signs the cart’s digest with a passkey, sees exactly what they sign, and cannot approve a cart they requested. A changed line voids the vote. Where the browser supports Secure Payment Confirmation, the browser itself shows the amount and the payee.
The policy is your organization’s (“up to $25,000 the budget owner approves; above that, finance too”). An agent can draft a cart and never approve one.
Paying. Inside Frazer (servers, addresses Frazer sells, GPU commitments), billing applies the approved cart. Outside Frazer, the person pays at the vendor and uploads the invoice; a wire or a transfer is always handed to a person at the bank, with a payee the agent checked against the seller’s invoice. Card numbers never pass through Frazer’s API.
The check: the invoice against the cart (amount within 2 %, payee, lines), then the thing itself (the block registered, the license active, the server in inventory).

Browser work

When a vendor has no API, an agent may prepare in a browser in its sandbox: open the vendor’s pages, fill every field it may fill, and stop on the screen before the irreversible button. The person takes over, signs in with their own password manager, checks the screen and presses the button; nothing is recorded while a person controls the browser. The browser agent never holds a credential or a payment method, reaches only the vendor’s allowlisted domains for that task, and treats every page as untrusted input.

Act	Step-up by default
Fill a production secret slot; sign a cart; attest a judgment	A passkey bound to the object’s digest
Fill a non-production slot; connect; mark a `provision` or `physical` task done	A strong sign-in within 10 minutes
Delegate, snooze, decline	A signed-in session

Every request, reminder, delegation, submission, check, attestation and use of what was handed over is an audit row with both identities (the agent that asked and the person who acted), the plan and the session.

Waiting well

The plan keeps moving. The items that need the task are blocked with the reason (blocked {reason: PT-21453}), list_ready leaves them out, and everything else runs. When the task’s check passes, its items are released in the same transaction and are designed to be dispatchable within 2 seconds at p95.

The session parks and resumes. A session whose remaining work all waits on a person task writes a checkpoint and a handoff naming the task, then parks. It keeps its lease for up to 30 minutes when the kind usually takes a person under 10 minutes and the assignee was active in the last 10; otherwise it releases the lease, so it never holds an item for days, and dispatch offers the item again with the handoff when the task is done. A parked session costs storage only. Demo: Acme’s session s-8e20 works plan acme/plans#513; item 1.4 needs a new sandbox key for the payment gateway, so person task PT-0031 goes to lena at 11:40, she fills the slot from her phone at 11:58, Frazer verifies the key at 12:02, and the session resumes from its checkpoint after 22 minutes parked.

A timeout is never an answer. No timer completes, approves or drops a person task. A deadline that passes escalates; only a person ends a task.

Needed by, act by, reminders

Needed by is when the blocked work needs the result: the earliest start of what the task blocks, from the plan’s schedule and the program’s forecast. Act by is needed by minus the kind’s p90 lead time outside Frazer: the person’s own deadline, and the date on every row (“act by Oct 18”). Both move when the plan moves, with a notice when act by moves earlier by more than a day.
Reminders follow the slack, not a fixed timer: at the request, at half the slack, one working day before act by and at act by; at most one a task a working day, inside the cap of 12 immediate notifications a person a day, the rest in the daily digest. Quiet hours and time zones are the assignee’s.
Escalation follows the approvals engine: at act by the plan’s accountable person sees the task in Needs you; a working day later, the fallback assignees named in the plan or the squad join. A task on the critical path of a milestone at risk shows its effect (“moves #146’s p85 only if not done within 56 days”).

Delegation, groups and many tasks

Delegation routes work and never lends authority. The delegate must hold the permission the kind needs (adding versions to the secret’s folder, approving the cart, the role a registration needs). The delegator still sees the task under Waiting on others.
Group assignees: “anyone in platform-secrets who may add versions to fx/*”. The first to open the action holds it for 30 minutes, so two people never paste two keys.
One person owing many: tasks group by vendor and kind and sort by what they release per minute of your time, then by act by (“Brennmoor Bank · 37 key rotations · due this week · about 40 min in one sitting”). A batch slot takes all 37 keys on one page, each checked as it is pasted; stopping halfway keeps the ones done. Carts inside one policy can be approved as one batch of the approvals engine, and a four-eyes rule still needs four eyes.
Phones and chat. Every kind can be done in the Frazer app with a passkey, a secret slot included. Slack, Teams, email and push carry the row and a link to the action on Frazer’s origin, never the action itself for a secret, a cart or an attestation; a chat “Mark done” works for provision and physical tasks, because Frazer’s check decides.

Done means checked

The person’s “done” is a claim. Frazer runs the kind’s check, and the row reads verified; where no machine can check, the person attests with a passkey and the row reads attested.

Kind	The check	It fails when
`credential`	The least call through the egress gateway with the value injected; the scopes read back where the vendor allows	The call fails; the scopes are broader or narrower than asked; the key expires before the plan needs it
`connect`	Token introspection or the provider’s scope list, and one read call	Scopes are missing or extra
`provision`	The setting read back: a DNS query, an allowlist test call, the vendor’s API	The read-back differs
`register`	A registry or vendor lookup: RDAP for a registry ID or an address block; the account’s own `GET /me`	The record is missing or names someone else
`purchase`	The invoice against the cart, then the thing itself	The amount is off by more than 2 %, the payee differs, a line is missing, nothing arrived
`verify`	The person’s answer, attested	—
`physical`	The device answers: Redfish on its management controller, an LLDP neighbor, the serial in inventory	No answer within the check’s window
`judgment`	The document’s digest and the signer’s identity	Unsigned, or signed by someone else
`contact`	The reply is the evidence	—

A failed check returns the task to requested with the reason in one sentence and the one action that fixes it (“the key has rates:write; make one with rates:read only”). A check is designed to start within 2 seconds of a submission and to finish within 30 seconds at p95 for credential and connect tasks.

Recurring tasks, measured as toil. A secret at a vendor with no rotation API comes back as a task every 90 days. Frazer makes each rotation safe and quick (two valid versions during the overlap, the batch slot, the check) and measures person minutes and elapsed days per kind and vendor with what would remove them: “Connect the key APIs of 3 vendors: 702 of 1,031 monthly rotations become agent work”; “17 OAuth consents this month would be one grant”.

Fields and states

Field	What it holds
`title`, `why`	The task in one line; why it exists in two sentences at most, with links to the decision, requirement or item behind it
`kind`, `label`	One or two kinds; your organization’s word
`assignee`, `participants`	A person, or a group meaning anyone in it with the permission; dual control (a ceremony that needs 2 of 3 officers)
`accountable`	The plan’s accountable person
`needs`	What created the task: `secret_ref`, `connection`, `account`, `address_block`, `server`, `signature`, `fact`, `balance`
`agent_attempt`	What the agent tried, in which session, and why it stopped
`prep`, `steps`	What the agent prepared, each link from Frazer’s vendor catalog or the plan’s own sources; numbered steps, each with its own check and the date it was checked against the vendor’s documentation
`handover`, `check`	Where the result goes (`secret`, `connection`, `value`, `evidence`, `attestation`); how Frazer verifies it
`needed_by`, `act_by`, `not_before`, `deadline`	Computed dates; a hold before a request makes sense (a quote that expires); a hard outside date
`lead_time`, `effort_minutes`	The kind’s and vendor’s elapsed time outside Frazer at p50 and p90, from your history or a labeled default; the person’s own time
`cart`, `step_up`, `found`, `recurs`	A purchase’s cart; the step-up the act needs; `planning` or `runtime` (late); `every: 90d`

drafted ──(phase approved)──▶ planned ──(its own dependencies done)──▶ requested
requested ──▶ in_progress ──▶ submitted ──▶ verifying ──▶ done (verified | attested)
                 └──▶ waiting_external {party}          check fails ──▶ failed_check ──▶ requested
side states: snoozed · declined · superseded · dropped        flags: overdue · on_critical_path · late

A task is requested as early as it can be done, because outside lead times reward an early start. declined turns into a decision row for the plan’s owner (re-plan, another person, or drop); superseded means an agent path appeared (“done by an agent: the key API was connected”). In a plan file, a person task is written like any item:

## Phases
- P4 {#n-4a10} Addresses for the failover region · approved
  - 4.1.1 {#n-4a17} Buy two IPv4 /24 blocks for the failover region
    person: priya · kind: purchase, register · needs: address_block ×2 · check: rdap
  - 4.1.2 {#n-4a18} Route objects and RPKI ROAs for both blocks · depends_on: 4.1.1

Where person tasks appear

Surface	What appears
Today › Needs you	The Do group beside Decide, Approve, Confirm and Update: one row a task with its one action
My work	The same rows across projects
A plan’s page	A Person tasks tab: every task of the plan by state, with act by, needed by and the lead time between them
The Map	A ring on a tile whose subtree holds an open task, amber when it is yours (Programs)
Do next and Waiting on people	Tasks ranked with decisions and approvals by their computed effect; who owes what, since when and what it blocks
A session’s page	“Parked · waits for PT-21453” with a link
Slack, Teams, email, push	The row and a link to the action on Frazer’s origin

One row shape works in every list and every density (product UI, demo data):

◇ PT-21453  The FX rate provider's production API key     #411 5.1.1 · fx   blocks 12   act by today   ≈ 4 min   [Enter key]

Kind glyph (with its word for screen readers) · handle · title · plan and item · squad · what it blocks · act by · effort · the one action. Compact rows drop the squad and the effort, never the handle, the action or act by. Act by is amber when a person must act (inside a day, or late, with the words “1 day late”); red is kept for a failed check, and neither color is the only signal. Space peeks at the why, what the agent tried and the steps without leaving the list.

At 1,000 and 10,000 open tasks the organization’s list follows the rule for every list at scale: its counts first, adding up to the total, each a filter (“63 need you · 1,151 with others · 1,214 open”, then the filters “41 overdue · 1,031 rotations · 9 late this month · 3 h 10 min your time”); exception groups next (“Brennmoor Bank · 37 rotations due this week · platform-secrets · one sitting”; “4 tasks past act by on critical paths”; “9 late tasks · 6 from one missed rule”); then groups by vendor, kind, plan, person or state that roll up in one line each; Compact rows of 28 px inside an opened group, virtualized to 100,000; bulk actions only within authority (delegate a group to someone who holds the permission, snooze a group until an event, open a batch slot; never fill, sign or approve in bulk outside the approvals engine’s batches); and a toil strip with the three removals that save the most person minutes. One person’s list with its groups and counts is designed to read in 25 ms at p99.

Keys: J and K move · Space peek · ↵ open with the action focused · A approve a cart (passkey) · H snooze until a time · ⇧H until an event · @ assign · X select · / filter · ? every key.

Demo: Pellwyn at 15:00 on Oct 17

Program pellwyn/plans#120 “Real-time ledger” has 25 person tasks: 19 done (16 verified, 3 attested) and 6 open, owed by 4 people and holding 70 items on 4 tiles of the Map. One task this month was found late. Person minutes this month: 3 h 10 min.

Handle	Item	Kind	Task	Owed by	Act by	Blocks
`PT-21451`	#420 4.1.1	purchase · register	Buy two IPv4 /24 blocks for the failover region (`198.51.100.0/24`, `203.0.113.0/24`)	priya	Oct 16, 1 day late (needed by Nov 6: the failover racks arrive Nov 5)	31 items in #420 P4
`PT-21452`	#413 6.1.1	register	Sign Brennmoor Bank’s sandbox agreement (a click-through signature, four clauses summarized)	priya	today	18 items in #413 P6
`PT-21453`	#411 5.1.1	credential	The FX rate provider’s production API key (Ratewell); the slot is ready	the fx squad’s key holder	today	12 items in #411 P5
`PT-21454`	#401 8.3.1	provision · physical	Provision the hardware security module partition for ledger signing keys	a partition officer (two hold the token)	today, with 56 days of slack	9 items in #401 P8
`PT-21455`	#413 6.2.1	provision	Add Pellwyn’s egress addresses to the bank’s sandbox allowlist (console only); late: found at 10:41 by a 403	the fx squad’s key holder	today	6 of #413 P6’s items
`PT-21456`	#409 3.1.4	judgment	Tax counsel’s opinion on reversal dates, evidence for decision #312	kenji	Oct 15, 2 days past	decision #312 (14 items)

PT-21451, the purchase, end to end. The agent found no broker or registry API Pellwyn is connected to: a transfer needs Pellwyn’s administrative contact at the regional internet registry, signed agreements and a payment. It prepared the cart, two broker agreements, the registry’s justification text and the steps, checked against the registry’s pages on Oct 16. priya’s row reads “Approve $16,128”: 256 addresses at $31 from one broker and 256 at $32 from another, a third quote at $28 an address rejected for its blocklist history; the budget of #420 is $20,000 with $1,240 spent; the policy says up to $25,000 the budget owner approves. After the passkey vote come four steps: sign both broker agreements, submit both transfer requests with the prepared text, finance sends the escrow wire, and sign the registry’s agreement when invoiced. After that, Frazer reads RDAP for both blocks and expects Pellwyn’s registry ID; route objects and RPKI ROAs (item 4.1.2) are agent work. A day late at the transfer’s p90 means the blocks may arrive a day after the racks, and the program’s forecast says no milestone moves unless they arrive after mid-January.

PT-21453, the slot. One narrow page with no navigation: “Requested by s-5c35 for #411”, the secret fx/rates-provider-key, Who can use it (sessions bound to #411; the fx-rates workload in pellwyn-production), Sent only to api.ratewell.example, Expires in 90 days with a rotation task, one paste field with its format hint (“starts with rw_live_”), What happens next (“Frazer calls GET /v2/account with this key and checks it has rates:read only”), the passkey button Save key and the line “The agent never sees this value.” At 15:02:11 the check line reads “Verified · GET /v2/account → 200 · scopes rates:read only · expires Jan 15 · 12 items released to fx · rotation PT-21499 planned for Jan 8”.

At organization scale Pellwyn has 1,214 open person tasks across 46 programs and 312 people: 1,031 key rotations (3,920 of its 9,800 secrets sit at vendors with no rotation API, 90 days each) and 183 others. platform-secrets owes 412 of them, and 37 at Brennmoor Bank are one sitting this week.

Commands and tools

fir person-task list --for @me
fir person-task view PT-21453
fir person-task delegate PT-21454 --to diego
fir person-task check PT-21453

fir pt is the short form; fir person-task request creates one from the command line.

MCP tool	Does	Toolset
`request_person_task`	Creates the task: its kind, needs, why, what was prepared, the handover, the check and what it blocks; refused without what the agent tried	Default
`get_person_task`, `list_person_tasks`	A task; tasks by assignee, plan, state or kind, with counts and groups as data	Default
`create_secret_slot`	A slot for a secret, its readers, hosts, format and expiry; returns the slot’s handle and URL, never a value	Default
`create_connection_request`	An authorization URL with the plan’s scopes, or a device code	Default
`draft_cart`	A cart for the approvals engine: lines, quotes, the budget	Default
`check_person_task`	Runs the kind’s check	Default
`wait_for`	Parks the session on a person task; it wakes on the task’s check	Default

The API is PersonTaskService in frazer.records.v1 (CreatePersonTask, GetPersonTask, ListPersonTasks, DelegatePersonTask, SnoozePersonTask, CheckPersonTask); the slot and the cart are served by the secrets and approvals APIs. Events: records.person_task.created, .requested, .started, .submitted, .verified, .attested, .failed_check, .delegated, .snoozed, .declined, .superseded, .reminded, .escalated, and secrets.slot.filled, which never carries a value.

Programs: rings on the Map, Today’s Do group, Do next and Waiting on people
The planning flow: the plan checks that find person tasks
Agents and plans: parking, resuming and handoffs
Secrets: where a slot’s value is stored and how it reaches a program