AMETYST

Test Accounts

Policies

Facilitator Registry

Credits & Design Partners

Every Allowed email gets access + free credits and is marked a design partner by default, so Allowed ⊆ Design partners: an allowed partner is always a design partner, but a design partner is not necessarily allowed.

Allowed

Design partners

Task Proposals

Stateful Integrations (Connections)

Registering a connector writes four artifacts in one transaction: the capability row, the connector spec, the composition-instructions card and one skill row per operation. A connector with 0 skills or no instructions is invisible to getAllowlist however correct its spec is — both are shown in the table below. A connector with no source descriptor (none in the Source column) is a third way to be invisible: cli 0.2.101+ drops a sourceless entry from the user's catalog, so the provider looks healthy here and does not exist for the client. To edit a registered connector, click its Edit button: the whole row loads into the register form below, and Register re-registers it in place (the endpoint is a whole-row upsert). A row registered before the card brief was stored comes back with the five brief boxes blank — restate them once.

Transactions

One partner's spend: settled rows, pending consumes and projected credit mints, in one union. Amounts are base units — the decimal shown is exact (BigInt), and the raw integer is on the cell's tooltip. The provider filter takes a bucket key (provider:<name>, bucket:legacy, bucket:top-up), which is why its options come from the totals grid rather than from typed-in names.

Sign-up bonuses

Credits minted once, when a workspace finalizes: one amount for every new workspace, and a different one for a workspace whose profile is flagged as a design partner. Saving changes nothing retroactively — it arms every future finalize, which is why the save is confirmed on prod even though it writes no chain.

Billing alerts

What Stripe reported about a payment that needs an operator: a dispute, a fraud warning, a reversal that could not take all the credit back, a payment that could not be credited. A dispute or a fraud warning also freezes the workspace for new payments; the credit it already holds stays spendable. Acknowledge what you have looked at; lift a freeze once the dispute is acknowledged.

Plans

What each workspace plan grants. One saved cell changes what every workspace on that plan may do, within about a minute — which is why the save is confirmed on prod even though it writes no chain.

AI prices

What each AI plan costs per month and what each model costs per million tokens, in EUR. The services read these lists as they are, so a saved row is the price from then on — which is why a save is confirmed on prod.

Customer plans

The plan each workspace is on. Pick a plan on a row and press its Save to move that one workspace; the row then shows what the server stored. The expiry is never changed here. Under each workspace, one row per member with their own plan and where it came from (subscription / operator / —); Make Pro or Make Pay per use moves that one member. A member whose Pro is paid by the workspace subscription cannot be changed here.

Endpoint Pricing (Merchant Economics)

Per endpoint: the price we charge, the cost we pay upstream, the markup between them, and what the last 30 days of calls were worth.

Every amount is base units (×10⁶). The decimal shown is exact (BigInt); the raw integer is on the cell's tooltip. Editing the markup shows the price that would be written — ceil(cost × (10000 + bps) / 10000) — before anything is saved or applied.

A dash is not a zero. — means the value has never been recorded (or could not be read); 0.000000 and 0% mean it was recorded and it is zero. Most of the pass-through fleet really does run at exactly 0% markup — that is the finding this table exists to make visible, and it must not look like missing data.

Recording and applying are two acts. Save writes the cost and markup and moves no price. Apply derives the price from the saved row and writes products.price and the bazaar row in one transaction, with an audit entry. Verify asks the live staging merchant what it actually quotes. Writes are staging-only server-side.

Merchant Integration (x402)

How to onboard a stateless x402 merchant — a pay-per-call provider with no user account or stored state on our side. This is the manual runbook; every step below happens in the tools it names, not in this console.

Ametyst Agent — getAllowlist

When a customer's agent calls getAllowlist, the Ametyst Agent chooses the skill with Jev from this catalog: every skill of the platform with a short line, an excerpt and a domain. Sync catalog reads every skill of the platform and rewrites only the new and changed ones (a few cents each); unchanged skills cost nothing. Reclassify all asks Jev the domain of every skill again, for after the domains changed: it only proposes moves, checks them on the test set, and writes nothing until you apply. Staging only.

1. ANSWER  (under a second, at every request)

   agent: "what do I use for X?"
        |
        v
   Jev picks the DOMAIN  -->  Jev picks the SKILL inside it
                                   |
                                   |  at the same time: "is X the same kind of request as an
                                   |  EXAMPLE approved for this member / workspace / everybody?"
                                   v
                          yes (85% or more) -> the example's skill, alone
                          no                -> Jev's own choice
        |
        v
   answer to the agent  +  one row in "Latest decisions"


2. WATCH  (by itself, always)

   the agent uses a skill  -->  written next to the decision ("What the agent used next"):
                                followed / another one proposed / another app


3. LEARN  (once a day, or "Run review now")

   decisions that ended with another app
        |  Jev groups the ones that asked the same kind of thing
        v
   3 cases in 2 sessions?  -->  a PROPOSAL: "requests like this -> this skill"
        |                       for one member / one workspace / everybody
        |  tried on the test set: dropped if it answers worse
        v
   YOU: Approve / Refuse  -->  it becomes an EXAMPLE  -->  back to 1

Ametyst Agent — Session advice

While a member's agent works, the Ametyst Agent looks at the conversation every 20 events and on each prompt, and says one line when it sees a known waste (retry too fast, same search rephrased, paid after a free search, …) or when a prompt needs an app and getAllowlist was not called. The line reaches the agent at its next action as Ametyst Agent: …. Whether it was followed is read from what the conversation did next: Followed (the waste stopped, or getAllowlist was called), Ignored (it went on), No later activity (nothing more within 30 minutes), Not delivered (the cli never took it). Staging only.

1. LOOK  (while a member's agent works; the line arrives about 20 seconds after the fact)

   what the agent does (prompts, tool calls, results)  -->  stored by the gateway
        |
        |  every 20 events, or 5 events older than 2 minutes, and on each prompt
        v
   Jev reads the last 40 events against the PATTERNS of that member:
   everybody's + its workspace's + its own, minus the ones MUTED for it
        |
        +--  a pattern at 75% or more (50% while the agent is stuck or wasting)  -->  ONE LINE
        +--  a prompt that needs an app, and no getAllowlist in the next 5 events  -->  the REMINDER
        +--  anything else                                                         -->  silent
        |
        v
   "Ametyst Agent: ..." at the agent's next action   +   one row in "Lines said"


2. WATCH  (by itself, from what the conversation does next)

   the waste stopped, or getAllowlist was called     -->  Followed
   it went on                                        -->  Ignored
   nothing more within 30 minutes                    -->  No later activity
   the cli never took the line                       -->  Not delivered

   3 Ignored in a row, same member, same pattern     -->  MUTED for that member, by itself
                                                          (a Followed in between resets the count)


3. LEARN  (once a night, or "Run review now")

   a pattern said 10 times or more in 30 days, followed less than 1 time in 5
        -->  a PROPOSAL to retire it

   a waste seen 3 times in 2 conversations, and no pattern for it
        |  a model writes the pattern from those sessions (no e-mail, URL, path or long number)
        |  Jev tests it: recognised on its own cases, no test window changing verdict
        v
        -->  a PROPOSAL to add it, for that workspace (or everybody when 2 workspaces saw it)

   YOU: Approve / Refuse / Undo  -->  it becomes a PATTERN (or one is switched off)  -->  back to 1

Treasury

The treasury account's money, for invoicing: current balance, every on-chain transfer in and out, and who the counterparty was. Every amount is base units (×10⁶), shown as an exact decimal — the CSV carries both forms. A counterparty label is operator-curated: merchants' payTo addresses are not recorded off-chain anywhere, so name them here (click Label on a row) and the name sticks for every future transfer.