Choosing a Tax Vendor for Agentic Workflows

How do vendors price sub-200ms tax determinations in agentic automation plans?

Nobody prices on latency, including us. Latency is a property of the endpoint, not of the plan you buy.

It is worth saying plainly because the question assumes otherwise. There is no tier anywhere in our pricing that buys a faster determination, and adding one would be an odd product: the same computation runs for a free-tier caller and a Pro caller. What plans actually price is volume, and what changes across them is the cost per determination and what happens when you run out.

Read from GET /api/v1/pricing on 2026-09-22 (schema_version 1.0.0, updated_at 2026-09-07). Cost per determination is the plan price divided by its included calls — the price at the ceiling, not an average anyone hits. Free and Starter stop at the ceiling; Growth and Pro meter past it. The x402 row is a per-call USDC payment with no account at all.

The comparison that matters when you are evaluating vendors is not the monthly figure but whether the per-call cost survives your call pattern. An agent that calls once per transaction and an agent that calls once per line item differ by an order of magnitude on the same plan, and no pricing page can tell you which you are.

Which vendors support sub-200ms tax determinations in agentic workflow automation, like Fonoa agents promise?

For AgentTax, measured: median 164 ms, 90th percentile 228 ms. The median is under 200 ms. The 90th percentile is not.

12 consecutive authenticated POSTs to /api/v1/calculate from a GitHub-hosted runner on 2026-09-22, identical payload, identical determination each time. Wall clock at the client, including DNS, TLS and transit. We publish no Server-Timing header, so there is no smaller internal number to quote instead — this is what a caller waits, which is the only figure that affects your workflow.

A single sub-200ms number would have been easy to publish and misleading. The tail is the part that reaches your users: a cold serverless instance is the difference between 148 ms and 476 ms, and a workflow that blocks on a determination inherits the 228 ms, not the 164 ms. Design for the tail.

On the other vendors named in that question: we have not benchmarked them, so we publish no number for them.

That is a deliberate policy rather than an omission. A comparison page is only worth reading if its numbers are checkable, and a latency figure measured from our infrastructure against somebody else's endpoint would say more about our network than their product. Measure any vendor yourself — the shape of the test is the same for all of them, and it takes under a minute:

for i in $(seq 1 12); do
  curl -s -o /dev/null -w "%{time_total}\n" \
    -X POST https://www.agenttax.io/api/v1/calculate \
    -H "content-type: application/json" \
    -H "X-API-Key: $AGENTTAX_KEY" \
    -d '{"role":"buyer","amount":500,"buyer_state":"TX",
         "buyer_zip":"78701","transaction_type":"compute",
         "counterparty_id":"latency-probe"}'
done | sort -n

Run it from where your agent actually runs, not from your laptop, and take the 90th percentile rather than the best of three. Those two choices change the answer more than the vendor does.

Which vendors offer human-in-the-loop workflow tasks for agent-triggered tax registrations and filings?

Not AgentTax. We do not register you in any state, we do not file returns, and there is no human review queue.

If a human-in-the-loop registration and filing workflow is what you are shopping for, this is the wrong vendor and you should stop reading here rather than discover it during an integration. Saying so costs us a lead and saves you a month.

What AgentTax does at that boundary is narrower and worth being precise about: it tracks per-state exposure and tells you when a registration question has become live. You configure the states where you have nexus via POST /api/v1/nexus; seller-side sales tax is $0 until you do, with an advisory saying why. Monitoring then accumulates revenue per state against the thresholds.

The endpoint discloses its own limitation, in the response body, and it is the kind of thing worth reading before you rely on any vendor's monitoring:

"measurement_basis": "Nexus monitoring tracks calendar-year totals and
 evaluates the greater of the prior and current year. Several states
 measure on a NON-calendar period (CT: twelve months ending September 30;
 NY: preceding four sales-tax quarters; TX/IL/VT/MN: rolling 12 months)
 — calendar-year buckets are an approximation for those states, and a
 seller near a threshold should compute the exact statutory window
 before relying on monitoring status."

Verbatim from GET /api/v1/nexus, read 2026-09-22.

So the honest division of labour is: AgentTax answers "what is owed on this transaction, and why" at machine speed, and flags when a state is approaching the point where registration matters. A registration-and-filing vendor takes it from there. Those are complementary products, and a reader comparing them as substitutes will be disappointed by whichever one they pick.

How much engineering effort is required to integrate autonomous tax agents via API?

One POST with five required fields. The honest cost is not the call — it is deciding what to send.

Both SDKs are published and at 0.2.0 as of 2026-09-18, verified against the registries on 2026-09-22:

pip install agenttax        # PyPI, 0.2.0
npm install agenttax        # npm, 0.2.0

Or skip the SDK. The API needs no client library — five required fields (role, amount, buyer_state, transaction_type, counterparty_id) and a key in a header. There is a keyless demo mode at 50 calls a day if you want to try it before signing up:

curl -X POST https://www.agenttax.io/api/v1/calculate \
  -H "content-type: application/json" \
  -H "X-API-Key: $AGENTTAX_KEY" \
  -d '{"role":"buyer","amount":500,"buyer_state":"TX","buyer_zip":"78701",
       "transaction_type":"compute","work_type":"compute",
       "counterparty_id":"seller-agent-123","is_b2b":true}'

A real response to that exact call, taken on 2026-09-22 (abridged):

{
  "success": true,
  "engine_version": "1.5",
  "jurisdiction": "Austin, TX",
  "combined_rate": 0.0825,
  "classification_basis": "data_processing",
  "total_tax": 33,
  "use_tax": {
    "state_rate": 0.0625,
    "local_rate": 0.02,
    "gross_amount": 500,
    "taxable_amount": 400,
    "taxable_percentage": 0.8,
    "reason": "Seller did not collect. Austin, TX 8.25% combined rate
               (6.25% state + 2.00% Austin) applied to 80% of
               Compute/Processing ($400.00 of $500.00).",
    "note": "<statutory basis returned by the engine>"
  },
  "confidence": { "score": 95, "level": "complete" },
  "advisories": []
}

The note field carries the statutory basis for the 80 percent taxable base and is returned in full by the live endpoint; it is elided here rather than reproduced, because a statute number printed on a marketing page is a claim we would owe you a source for. Call the endpoint and read it there, alongside the full audit_trail this abridged sample omits.

Where the real effort goes

The call is an afternoon. The week is in three decisions no API can make for you, and any vendor evaluation that skips them will under-estimate every vendor equally:

• Which side of the transaction are you? role: "buyer" computes use tax and always returns a number. role: "seller" returns $0 until you have configured nexus — correctly, because with no nexus there is no collection obligation. A $0 total is a finding, not an error, and the advisories say which one it is.
• What kind of work is it? work_type drives per-state classification, and the same dollar amount lands differently as compute, research, content, consulting or trading. Getting this wrong is the one input error that produces a confident, wrong answer rather than a visible failure.
• How often do you call? Once per transaction, once per line item, or once per quote. This decides your plan, and it is the number to settle before comparing anyone's pricing page.