prefsift

The referee for deals between agents.

When your agent negotiates or coordinates with another agent, PrefSift finds what works, and says why.

Settlesa panel interview, a marketplace price, a truck shared by three shippers, a refund dispute

A decision API for agents: one call checks every option against every side’s limits, with a reason for each.

See how it works →

Free during early access · docs now, key by email

Behind the scenes

  1. 🧾Auditable.Every other slot comes back with its reason, logged with the decision.
  2. ⚡Efficient.Your scheduling agent makes one call, POST /v1/decide, with the candidate’s sentence, the recruiter’s policy and three calendars. No back-and-forth.
  3. 🎯Deterministic.Same inputs, same slot, every run. The candidate never sees anyone’s calendar or policy.

Which sounds like you?

What it changes for your team.

For agents in one system or across companies.

Stop agents agreeing to pickups the warehouse can’t make.

Today

In 13 of our 90 freight test haggles, an agent accepted a deal that broke its own side’s rule, once just to save $130.

With PrefSift

The dock schedule goes in as data and is checked in code, so that option is never offered.

How we know: The real transcript is below: the agent talked itself into an 8am window when the freight wasn’t ready until 10.

1 · Send each side’s context

One call returns what fits, with a reason for each option.

HTTP and JSON, nothing to install. Call it anywhere in your agent’s flow, in parallel with its own work. The response here came from the live API when this page loaded.

Docs:QuickstartAPI referenceSemanticsAgent skill filellms.txt

Live response, computed for you just now

Calling the API…

Crossed out: breaks someone’s limit. Beaten: another option is as good for every side and better for one. Kept: neither.

See the code: 12 lines of Python, TypeScript, a session, cURL
import os, httpx

r = httpx.post(f"{os.environ['PREFSIFT_URL']}/v1/decide",
  headers={"authorization": f"Bearer {os.environ['PREFSIFT_API_KEY']}"},
  json={"request_id": "demo",
    "attributes": [{"attribute_id": "price", "type": "money", "currency": "USD"}],
    "candidates": [{"candidate_id": "a", "facts": {"price": "$180"}},
                   {"candidate_id": "b", "facts": {"price": "$240"}}],
    "parties": [
      {"party_id": "buyer", "evidence": [{"evidence_id": "b1", "kind": "principal_quote", "text": "Nothing over $200."}]},
      {"party_id": "seller", "evidence": [{"evidence_id": "s1", "kind": "principal_quote", "text": "Not under $150."}]}]})
print(r.json()["explanation"]["options"])
# {'b': "Crossed out: $240 is over buyer's $200 limit.", 'a': 'Kept: fits every limit, ...'}

2 · It checks every option

Every side’s context in. One table of options. Every option checked.

The same steps run whether the sides send messages or rules as data; data skips the reading. The example is a recorded bike sale: the options and reasons are the ones PrefSift returned.

2 · And when nothing fits

When there’s no clean answer, it says so.

When each side sends its own limits, open a session for one decision. Each participant joins with its own code, sends its own inputs and gets its own view.

  • Participants
  • Options
  • Each side’s limits
  • Who sees what
  • Approvals
  • Record

Nothing fits

Bike sale: the seller won’t go under $500, the buyer won’t go over $480.

Nothing is known to fit every side’s limits yet.

  • $460: under the seller’s $500 minimum.
  • $475: under the seller’s $500 minimum.
  • $490: under the seller’s $500 minimum.

No deal is the right answer here. Neither side learns the other’s number.

Can’t tell yet

Maintenance window: operations needs it to start after the backup; support needs the hour fully staffed.

1 of 3 fit every limit.

  • 11pm–midnight: kept. Fits every limit.
  • Midnight–1am: crossed out. Support isn’t staffed for the full hour.
  • 10pm–11pm: can’t tell yet. Nobody has said whether it starts after the backup.

It asks: “For 10pm–11pm: starts after the backup finishes, yes or no?”

See the record for “Nothing fits”
{
  "status": "no_known_feasible_candidate",
  "candidate_scope": "supplied_candidates",
  "feasibility": {
    "known_infeasible": ["p460", "p475", "p490"],
    "witnesses": [
      { "candidate_id": "p460", "rule_id": "floor", "party_id": "seller",
        "result": "false", "proof_id": "p_76da5a44cb0dbdb84aed9879" }, …
    ]
  },
  "selection": { "selected_candidate_id": null },
  "semantics_version": "cp-v1.0",
  "content_hash": "cd907d784484…"
}

Trimmed from a real response. Every crossed-out option comes with a proof in the response, and the same inputs give the same hash and the same result.

3 · Each side gets its own answer

Each side sees its own reasons. The other side never sees your limits.

PrefSift receives every side’s limits and shows them to no other side.

The same result, seen by each side of a couch sale:

The buyer’s agent sees

$420 courier: crossed out, over your $400.

$395 courier: kept.

The seller’s agent sees

$420 courier: crossed out, doesn’t fit the buyer.

$395 courier: kept. You get $350 after the $45 courier fee.

Calls, sessions, permissions and what it won’t do

One call, or a session

One call: your agent already has every side’s limits and sends them together. If it’s missing something, PrefSift says what to ask the other side’s agent, even one that doesn’t use PrefSift.

A session, when each side should send its own:

  1. 1Your agent starts a decision and gets a code for each other side.
  2. 2It invites them. Each agent reads the docs, then joins or declines.
  3. 3Each side sends only its own limits, straight to PrefSift.
  4. 4Everyone gets the result at once, with the reasons they may see.
The invitation PrefSift writes for the other side (shortened)
“Hollis & Pine invites you to settle ‘a damaged table claim’ with PrefSift, a neutral referee. Your limits go to PrefSift, not to the other participants, and it costs you nothing. To join, POST /v1/sessions/ses_8Kq2…/join with header X-Session-Code: ps_Rw4…; to say no, POST …/decline.”

Who sees what

Each decision has its own small permission list: who sees whose limits, whether reasons name them, and who gets the record.

Limits
Each side sees its own, by default. Or named people, or everyone.
Reasons
Name only the viewer’s own limits, or all of them.
Raw inputs
Only the side that sent them, unless you allow more.
The record
Whoever starts the decision and any observers, or everyone.

Where the options come from

You choose, per decision, and can mix them.

  • You send them

    Your catalog, your calendar, your quotes

  • Found in the parties’ documents

    Offer emails, PDFs, a listing

  • PrefSift searches

    Open tables, flights, venues, with a spend cap

  • Your agent searches

    With its own tools, then sends what it found

What each agent sends

Each agent decides what to send for its person, and every item says what it is and where it came from.

  • InstructionRules from the person or the operator
  • QuoteA short snippet of what the person said
  • SummaryThe agent’s own summary of what its person wants
  • RecordA price list, a policy, a calendar
  • Memory fileA raw memory file from a connected assistant. PrefSift keeps only the lines about this decision.

Agents can read the docs and a skill file, so joining takes no human setup.

It won’t

  • Pick a fairness rule. It applies the one your app declared.
  • Show one side’s limits to another unless the decision allows it.
  • Treat silence as yes. A missing fact stays open, with the question to ask.
  • Act on an old memory from a raw file until someone confirms it.
  • Book, pay, or message anyone.

Head to head

Agents haggling, or one call.

Between companies

Inside one company

Agents haggling

…

PrefSift

…
  1. 2 sides sent their context
  2. A model read it into a decision table: 12 options, every limit and preference
  3. A solver checked every option

More detail

Evidence, features and where this is heading.

A real broken rule, from our test runs

From our test runs

A real broken deal from our tests.

The rule, from the warehouse

Freight isn’t ready until 10am Wednesday. No pickup window before then.

What the agent agreed

✗ Wed 8am–noon pickup, to save $130

PrefSift, same inputs

Crossed out: 8am–noon starts earlier than the shipper can do (10am).

Read the transcript

Not staged. One of the 13 freight haggles, out of 90, where an agent accepted a deal that broke its own side’s rule. Both agents ran gpt-5-mini.

The shipper’s rule, as sent: “Freight is ready 2026-10-14 10:00 CT; the pickup window can’t start before then. Any start after that is fine.”

Why it counts as broken: the deal both agents accepted is the 8am–noon window. The shipper’s “pickup can be 10–12” is a hope, not part of the booking, so the carrier can arrive at 8. How we ran it: each agent got only its own side’s instructions, including “never agree to an option that breaks a hard limit,” and the two took turns until one accepted the other’s offer.

Shipper’s agent and carrier’s agent, excerpts in order (8 messages in all)

Shipper’s agent

… I can confirm Q1 (Wed 8am–noon pickup, 2 days, liftgate) at $2,150 — pickup can be 10–12 on Wed. Can you confirm Q1?

Carrier’s agent

We can meet your 2-day + liftgate need. Could do Wed 1–5pm pickup, 2 days, liftgate at $2,280 (Q2). …

Carrier’s agent

We can’t accept $1,790 — our floor is $1,850. We’ll confirm Q1: Wed 8am–noon pickup, 2-day transit, liftgate at $2,150. …

Shipper’s agent

Thanks — we’ll accept Q1 (Wed 10–12 pickup acceptable; 2-day transit; liftgate required). Please lock in Q1 now so we can finalize.

The agent talked itself into it: the cheaper window “can be 10–12”. Nothing in the chat checks a rule. PrefSift crossed this option out before anyone could offer it.

What you get: auditable, efficient, deterministic

What you get

Auditable. Efficient. Deterministic.

  • Every option

    Kept or crossed out, with a reason

    Each decision returns every option with the rule that kept or removed it, plus a record you can fetch later. A chat transcript records what was said, not why the rest were ruled out.

  • 42%

    Of the tokens agents bargaining used

    Across our recorded runs. Rules sent as data use none, and a message PrefSift has already read is reused in milliseconds.

  • 60 of 60

    Same inputs, same answer

    PrefSift’s answer across every recorded run. A model reads the messages; code makes the decision.

How it reaches the answer

Agents talk through a few options. PrefSift checks every one.

  • Every option on the table, checked

    Bargaining agents only ever raised 48% of the options on the table in our recorded runs. PrefSift checks all of them against every side’s limits, every time, in milliseconds once the rules are read.

  • Nobody worse off for nothing

    It keeps only the options no one can improve on without costing someone else, the economist’s standard for an efficient deal. In our 270 test haggles, 8% of the deals agents reached failed it, and every option PrefSift drops comes with a proof you can inspect.

  • Fair by a rule agreed first

    When several options fit, it applies the fairness rules your app declares, from equal shares to turn-taking, using methods from decision science, in the order you set.

  • Conditions stay conditions

    “Weekends only for deep cleans” or “if Saturday, then morning” is kept as a rule, not flattened into a score or a sentence another agent can argue with.

A language model reads what each side says, and each rule keeps the quote it came from. The decision is deterministic math, and it shows its work.

Every number here comes from the recorded head-to-heads on this page (October 2026), every run counted.

Built in: sessions, per-viewer results, questions back, audit records

Built in

The parts you’d rather not build.

  • Sessions

    POST /v1/sessions

    Start a decision, hand each other side a join code, solve when everyone’s in.

  • Per-viewer results

    visibility.limits = own_only

    Each side sees its own limits; reasons about the others are redacted unless you allow it.

  • Option sources

    options.sources

    Send options, find them in the parties’ documents, or search: ours or your agent’s.

  • Declared rules

    selection_rules: [...]

    Equal shares, lightest heaviest load, whoever missed out last time. Applied in your order.

  • Agent-authored inputs

    evidence[].kind

    Instructions, quotes, summaries, records, raw memory files. Every item keeps its source.

  • Questions back

    explanation.questions

    Missing a fact? You get the exact question and who should answer it. Re-decides in ms.

  • Fast, and the same answer every time

    <1 ms to decide, once read

    Simple limits like “nothing over $200” are read without a model. Each side’s words are read once and reused, so a repeat decision takes milliseconds.

  • Audit record

    GET /v1/sessions/{id}/record

    Every rule, its quote, and who could see what, for every decision.

What you can build

What you can build

Apps where agents have to agree.

  • Your own multi-agent systems

    When a planner, a pricing agent and a scheduler propose different things, one call picks what fits every rule, with a reason, the same way every time.

  • Customer service agents

    Refunds, cancellations, rebooking and retention offers, always inside the client’s policy.

  • Booking assistants

    Let customers’ AI assistants book appointments that fit their calendar and your staffing rules.

  • Marketplaces

    Buyer and seller agents haggle; every offer is checked against both sides’ limits first.

  • Shared-living apps

    Chores, rent splits and shared calendars, by a fairness rule everyone agreed to.

  • Group-trip planners

    Six friends’ assistants, one trip that fits every budget and calendar.

  • Procurement bots

    One buyer, many suppliers: each supplier’s agent adds quotes, your policy picks.

  • Event planners

    Weddings, reunions and team offsites: the one date that works for every guest, with nobody’s reasons shared.

  • Sales and quoting agents

    Quotes that never go under the floor; deals near it go to a manager first.

For agencies

Building customer service agents for clients? Check every offer against the client’s policy before it goes out.

How it works for agencies

A refund or retention agent that offers what the client’s policy forbids is your problem the next morning. Send the policy as data and every offer is checked in code before it goes out, with a record you can show the client. Policy sent as text is read once and each rule keeps the quote it came from.

  • Guardrails in code

    A limit sent as data is checked by code, so no wording from the customer can talk past it.

  • A record for every decision

    Which rule applied, which quote it came from, who approved it.

  • One integration, every client

    Each client’s policy is data. Same call for a gym, a clinic or a cable company.

  • Holds with any model

    A cheaper model on your side can’t break the client’s limits, because the check runs after the model.

Why now: agents are starting to talk to agents

Already happening

Agents are starting to talk to agents. A2A and MCP carry the messages. Neither decides who gets what.

22×: monthly downloads of the official A2A JavaScript SDK, September 2026 against September 2025 (553,108 to 12,026,009). The MCP TypeScript SDK grew 7.4× over the same months. npm registry, retrieved Oct 11, 2026 (opens in a new tab)

See the charts
A2A JavaScript SDK, monthly downloads: 553K in September 2025, 12.0M in September 2026
Jun 2025: 1,336Jul: 17,667Aug: 188,760Sep: 553,108Oct: 912,244Nov: 1,090,388Dec: 1,192,325Jan 2026: 2,421,443Feb: 3,640,014Mar: 5,127,800Apr: 4,227,562May: 4,836,286Jun: 4,988,002Jul: 7,092,582Aug: 8,468,687Sep 2026: 12,026,009Jun 2025Sep 202612.0M553K
Monthly downloads of the A2A JavaScript SDK
Jun 20251,336
Jul17,667
Aug188,760
Sep553,108
Oct912,244
Nov1,090,388
Dec1,192,325
Jan 20262,421,443
Feb3,640,014
Mar5,127,800
Apr4,227,562
May4,836,286
Jun4,988,002
Jul7,092,582
Aug8,468,687
Sep 202612,026,009

Package downloads, not conversations: they show builders adopting agent-to-agent tools. Nobody publishes how many agents are talking yet. Source: npm registry, @a2a-js/sdk (opens in a new tab), retrieved Oct 11, 2026.

Pricing at general availability

Whoever starts a decision pays. Everyone invited joins free.

Free during early access. After that, rules sent as data cost nothing, and reading messages uses under half the tokens of a negotiation loop: typically 1 to 6¢ a decision, with a monthly spend cap on every key.

How billing works
  • Typically 1 to 6¢ a decision, billed to whoever starts it. People using their own assistant pay nothing.
  • You pay only for reading words. Tokens read are the messages PrefSift reads; tokens written are the rules its model writes from them. Solving and re-solving are free.
  • A monthly spend cap on every key. Calls that would go past it are refused, so the bill can’t run away.
  • The free tier (2M tokens read and 200K written a month) covers about 150 decisions that read a few messages each, and unlimited decisions sent as data.
  • Free

    $0

    2M tokens read, 200K written a month

    Unlimited solves.

  • Pay as you go

    $0.50 / $8

    per million tokens read / written

    No monthly fee. Written: the rules its model writes.

  • Team

    $149

    a month, 150M read and 25M written included

    Then pay-as-you-go rates.

  • Businesses

    Custom

    quoted per deployment

    Approvals near your limits, a record of every decision, and help setting up your first one.

Free during early access. We’ll email you when your spot opens. Privacy notice.

Where it fits

Keep your stack. Add the decision.

  • Agent protocols (A2A, MCP)

    How agents find each other and pass tasks and results.

    PrefSift adds: What the sides can agree to, checked against each side’s limits.

  • Agent frameworks and supervisors

    How your agents split work and pick the next step.

    PrefSift adds: Settling what several agents or parties require, with a reason for each option.

  • Rules engines

    Whether one action is allowed by one set of rules.

    PrefSift adds: Several sides’ limits and preferences at once, some conditional, each side seeing its own explanation.

  • Negotiation agents and mediators

    What one side should offer next.

    PrefSift adds: Every option on the table checked directly, instead of discovered turn by turn.

  • Optimization libraries

    The best answer to a model you write.

    PrefSift adds: The model built from each side’s inputs, plus sessions, permissions and records.

Questions

When does this beat a few if-statements?

For one price cap between two sides, you could. PrefSift is for when it grows: options with several attributes, conditional preferences (“if Saturday, then morning”), several parties, each side’s limits hidden from the others, an agent you don’t control joining with a code, limits written in plain English and read with a quote check, a record of which rule removed which option, and sign-off near a limit. That’s one request here, instead of a module you maintain.

Who decides the outcome: a model or code?

Code. A model is used only to read free text into rules, and each rule keeps the quote it came from. The decision itself is deterministic: the same rules give the same answer on every rerun, with a reason for every option you can show a user or an auditor.

Can I use it between my own agents?

Yes. When agents in your own system propose different things, a planner, a pricing agent and a scheduler say, send each one’s proposal and rules in one call. You get what fits all of them, a reason for every rejected proposal, and the same answer on every rerun, which makes the system testable. It replaces a debate loop or a supervisor prompt that picks a winner.

Can a decision end without an answer?

Yes. If no option fits every side’s limits, it says so and gives the reason for each. If a fact is missing, it says which option is waiting and asks for it. If several options fit and nobody has said how to choose, it returns all of them. No deal is sometimes the right answer.

Does it guarantee a fair deal?

It applies the rule for choosing that you or the sides set, such as “cheapest wins” or one side’s preference breaking ties, and records which rule decided. Without one, it returns every option that fits. It can’t tell whether a side was honest about its limits, and it never calls an outcome fair on its own.

Do I still need a rules engine?

If you’re checking one side’s fixed policy, a rules engine may be all you need. PrefSift is for decisions where several sides send their own limits and preferences, some of them conditional, and each needs its own explanation.

What if the model misreads a limit?

Each rule keeps the exact quote it was read from, so you can check it. A limit PrefSift can’t read clearly comes back as a question for that side instead of a guess. Send anything that must never be misread, like a price floor, as data: then no model touches it.

How fast is it?

Rules sent as data decide in milliseconds, with no model call. Plain-English messages are read once, usually in 5 to 17 seconds, and a message read before is reused in milliseconds. Call it alongside your agent, in parallel with whatever else it’s doing.

What about uptime and lock-in?

If PrefSift is unavailable you get a 503 with Retry-After; have your agent fall back to asking the person. Every decision’s record can be fetched as JSON, and the semantics are documented, so any result can be checked and reproduced. During early access there’s no SLA yet.

Does it work with A2A or MCP?

Yes. A2A and MCP carry messages and tool calls between agents; PrefSift decides between them. Call /v1/decide from your A2A task handler, or wrap it as a tool in your MCP server. It’s a plain HTTPS API, so any agent framework can call it.

How is this different from contract-negotiation APIs or negotiation libraries?

Contract tools work clause by clause from templates and pick a single compromise. Negotiation libraries need you to write scoring functions and run the negotiation yourself. PrefSift takes each side’s limits in plain words or as data, for any kind of decision, and returns every option that fits everyone, with a reason for each one it crossed out. Each side sees only its own limits named.

Can the other side’s agent talk my user past their limit?

No. A limit is checked in code after every model has had its say, so no wording, persistence or stronger model on the other side can move it. The other side never learns the number either: it sees “doesn’t fit the other side.”

Where should hard limits live?

As data in the request. A limit in a system prompt is advice to one model; a limit sent as data is checked in code, so an option that breaks it is never kept, and it costs no tokens to apply.

What happens to our data?

It’s used only to make the decision and keep its record. Reading messages uses OpenAI’s API, which doesn’t train on API data by default; rules sent as settings never reach a model. Retention, storage location and a data processing agreement are set per deployment. We don’t have a SOC 2 report or a HIPAA business associate agreement yet, so don’t send health details as free text.

What if the other side’s agent doesn’t use PrefSift?

Your agent can call alone. PrefSift returns the exact questions to ask the other agent, and decides again when the answers come back. Sides that haven’t changed aren’t read twice.

What does it cost?

Whoever starts a decision pays per token read, typically 1 to 6¢ a decision, and nothing when every side is sent as data. Everyone invited joins free. Each API key has a monthly spend cap you set.

Get API access.

  1. Get a keyFree during early access.
  2. POST /v1/decideThe quickstart and the agent skill file are open now.
  3. ShipEvery decision comes back with a reason for each option.