Most of these come from design-partner conversations and security reviews. Each answer is the answer we give in those calls — concrete, qualified where it should be, and linked to the relevant product page or doc. If something is missing, Jed personally replies to jed@beaumontconsulting.co.
If you walk away with one mental model: every agent request flows through a proxy in your path, which places an atomic hold on the live budget and decides whether to admit, throttle, or hold. Everything else is detail.
A financial control plane that sits between your AI agents and the compute they consume, enforces your spend rules — per-run, monthly, and yearly caps — as hard limits before money is spent, and produces one reconciled ledger that engineering and finance both trust.
Autonomous agents now hold real budgets and spend money on compute to do their work. Finance sees the bill after it lands. The median enterprise's monthly LLM spend is growing about 7.2× year over year, and a single multi-step agentic decision cycle costs $0.10–$1.00 against $0.001 for a simple call — cost compounds with autonomy.
Tools that exist today observe, alert, and throttle; none prevent a breach. Tarmac is the layer that prevents — the only place where a hard cap is enforced atomically before any compute is spent.
Gateways throttle and alert. Tarmac enforces. Every run goes through an atomic authorization hold against your real budget; an over-cap run is either throttled to a lighter tier or held entirely.
Gateways were built for developers and observability. Tarmac is built for the platform leader and the CFO at the same time, with finance-grade books that gateways don't pretend to produce. They are complements, not competitors — many of our customers keep their existing gateway and point it at Tarmac.
Modeled on a card network. Before a run is admitted, Tarmac places a hold on the remaining budget for the maximum dollar amount that run could spend. When the run settles, the hold is released and the actual cost is captured.
Concurrency-safe by design — there is no path where two runs simultaneously consume the same dollar, and there is no path where a run is admitted unless it provably fits. The concurrency invariant is enforced as a CI release gate: builds don't ship unless 10,000 random concurrent authorizations against random caps zero-error against the invariant.
Each agent's compute lane — an inference-API model family (e.g. Claude, GPT, Gemini) or a fixed GPU type — is set once at onboarding. It's the security- and compliance-relevant decision and we keep it frozen.
What Tarmac changes dynamically, on every run, is the model tier the agent gets: lighter when the budget is tight or the agent is low-priority, heavier when there's room. Within a Claude lane that's Haiku → Sonnet → Opus. Within a GPT lane that's mini → standard → pro. Within a GPU lane that's A100 → H100 → H200.
Each agent carries a priority tier (P0 through P3) you assign at onboarding. When the monthly cap tightens — measured as the pace of burn relative to days remaining — Tarmac throttles lower-priority work to lighter model tiers first, protecting P0 work at full tier as long as possible.
Throttling cascades P3 → P2 → P1 → P0 as pressure mounts. P0 is never throttled by automatic rebalance; you'd have to deliberately set a P0 cap below the lane's minimum-tier price for that to happen.
Inference and agent runtime are Phase 1 — that's where the runaway-spend pain is acute. Training and fine-tuning lanes are on the Year-2 roadmap, behind the GPU-rental lane adapter. Same authorization-hold engine, same ledger, same surfaces; just a different price-signal source and a different settlement cadence.
We never see your weights or your customer data at rest — we proxy individual requests and keep the metadata needed to bill and authorize. Storage of prompt and completion content is opt-in per workspace; the default is metadata-only.
The provider you've pinned in the lane keeps the content path. Tarmac is in the request path for authorization and routing, not in the storage path for content.
Tarmac is an in-path vendor, so the security review is the deal. We treat compliance as a Q1 program, not something to start after product-market signal — SOC 2 Type I is on the Q2 2026 calendar, Type II observation window opens in Q3.
Yes — proxy-first. Tarmac receives the agent's request, authorizes it against the budget, and forwards it to the model or GPU provider on your behalf using a short-lived scoped token. We do not hold long-lived customer credentials.
If our budget engine is unhealthy we fail closed: no admit, no spend. An outage of Tarmac is a paused fleet, not a runaway bill.
GRC platform is live. SOC 2 Type I is on the Q2 2026 calendar; Type II observation window opens in Q3 and the report lands in Q4. We run a public trust center and commission an annual third-party penetration test.
ISO/IEC 27001 is on the 2028 roadmap. HIPAA and FedRAMP are conditional on customer demand — we won't ship a half-baked program on either.
Workspace-scoped, short-lived tokens. The proxy holds no long-lived customer secrets in its control plane. When an agent makes a request, the proxy mints a per-request scoped token from your provider account using a delegated trust relationship you set up once at onboarding (OAuth client, IAM role, or service-account binding depending on the provider).
If Tarmac is breached, the blast radius is bounded by the time-to-live and scope of those tokens — typically minutes, not days.
Standard SaaS DPA terms: data minimization, sub-processor list, GDPR Article 28 obligations, SCCs for cross-border transfers, breach notification windows, retention and deletion timelines. Our DPA is public on the trust center.
Tarmac processes (a) authorization metadata required to bill and decide, and (b) opt-in prompt/completion content when you've enabled per-workspace storage. We do not use customer data to train models. Ever.
Default is fail-closed: the proxy returns 503 and the agent retries. No new compute is admitted while the engine is unhealthy. We pick that default because for most customers an hour of paused agents is much cheaper than an hour of unbounded spend.
If you prefer fail-open behavior for specific P0 agents (e.g. customer-facing support), you can opt in per agent — that path bypasses authorization and is fully reconciled against your caps once the engine recovers, with the receipts marked retro-authorized.
Tarmac runs on AWS, multi-region. US (us-east-1 + us-west-2) is the default. EU residency (eu-west-1 + eu-central-1) and UK (eu-west-2) are available on Enterprise. APAC residency is on the 2027 roadmap.
Audit ledgers are written to the customer's chosen region and never replicated across regions without explicit consent.
The append-only ledger is the audit trail. Every authorization, hold, throttle, settle, and release is a hash-chained entry; the chain is externally verifiable, meaning an auditor can replay a period from the chain without trusting Tarmac to render it.
Retention defaults: 7 years of audit ledger history included in every agreement. Custom retention windows and regional residency are available on request. Read access for an external auditor is a dedicated role; no contortion of the role matrix required.
3% of the AI compute spend Tarmac governs (with a $12,000 annual minimum), plus 1% of the savings Tarmac actually realizes for you. We never resell compute. We never charge per seat, per agent, per workspace, or per dashboard. No tiers — same model from your first agent to your thousandth.
Two components. Governance fee: 3% of the AI compute spend Tarmac governs, billed annually, with a $12,000 annual minimum. Performance fee: 1% of the savings Tarmac actually realizes for you, reconciled quarterly in arrears.
One model, no tiers. No per-seat fees, no markup on compute, no setup fee. In any quarter Tarmac doesn't deliver savings, the performance fee is zero — we only charge on savings we genuinely realize and report.
It's the dollar value of compute spend that flowed through Tarmac's authorization engine in the billing month — at the actual settled cost, not the held maximum. If a hold was placed for $4.10 and the run settled at $1.92, $1.92 is what counts toward governed spend.
Held-but-unsettled runs cost you nothing on the meter. Over-cap held runs that never executed cost you nothing on the meter.
No — there are no tiers. The same 3% rate applies from your first agent to your thousandth; the same performance fee applies to your first dollar of savings and your millionth. Every feature is in every agreement.
This matters because some of our design partners 3×'d their governed spend in the first quarter. We want them to scale with confidence — no re-papering, no tier upgrade conversation, no pricing wall to bump into.
Yes — and you should. Tarmac is provider-neutral; it actively prefers cross-provider fleets because the Compute Price Signal can play providers off each other within your pinned lane.
Both Growth and Enterprise tiers include unlimited lanes and providers. Team tier supports up to three.
Not yet. Today every customer comes through a working session — a 30-minute call to encode budgets, agents, and lanes, and to scope the SOC 2 / DPA review. The product is too in-the-path to launch a credit-card-self-serve experience responsibly.
A self-serve sandbox for evaluation (without authorizing real spend) is on the 2026 roadmap. Real production traffic will always require the working session.
Listings go live in Q3 2026 — AWS first, Azure and GCP in Q4. Buying through marketplaces lets your spend count against your existing committed cloud spend (MACC / EDP / CUD), which procurement teams love.
Marketplace contracts mirror the standard MSA, with marketplace-specific terms layered on top. Pricing is identical.
Annual contracts auto-renew; opt-out window is 60 days before renewal. The design-partner pilot agreement supports quarter-by-quarter cancellation in Year 1. Marketplace contracts follow the marketplace terms (typically 30-day notice).
On termination, your audit ledger is exported (JSON + CSV + parquet) and retained for your contracted retention window before deletion.
Design partners are typically in production on one team's fleet within two weeks of the security review clearing — usually one engineering afternoon to point traffic at the proxy, a few hours to encode budgets and agent tiers, and a brief reconciliation cycle for the first statement.
Proxy mode: under an hour to govern one agent. Pointing your existing OpenAI / Anthropic / Bedrock SDK at api.tarmac.dev is a one-line change.
SDK mode (per-call attribution): one afternoon for a small fleet. You wrap each call in a context manager that resolves the model tier and writes attribution metadata to the receipt.
End-to-end onboarding including security review: typically 1–3 weeks depending on your team's procurement cadence.
Phase 1 (MVP): Anthropic (direct and Bedrock), OpenAI (direct and Azure), Google (Gemini direct and Vertex), AWS Bedrock multi-vendor, Azure OpenAI. That covers ~95% of the production agent traffic we've seen.
Phase 2 adds Cohere, Mistral, xAI, and a customer-bring-your-own provider adapter. Same price-signal abstraction; new providers are a few hundred lines, not a rewrite.
Yes — all of the above, because Tarmac is API-compatible at the provider level. You configure the framework to point at api.tarmac.dev and use a Tarmac-issued key; the framework keeps using its native SDK calls and Tarmac authorizes each one transparently.
For frameworks that emit telemetry, we publish wrappers that propagate the Tarmac receipt ID into your trace stack so a span in Datadog or LangSmith links directly to the matching Tarmac authorization.
Authorization decision: p50 4ms, p99 14ms.
Proxy overhead per call: 7ms round-trip in the same region as your provider. Streamed responses are unaffected once authorized — we don't re-process the stream.
For agents making 10–50 model calls per task, total added latency is typically <1% of end-to-end task time. We invest aggressively in the hot path; it's a core SLO.
Yes. The most common pattern is: agent → gateway (logging, tracing, retries) → Tarmac (authorization) → provider. The gateway gets to keep doing what it does well; Tarmac adds the enforcement layer it can't.
For teams that don't already have a gateway, we cover the basic observability hooks directly so you don't need to add one just to use us.
The proxy is available as a containerized appliance for Enterprise customers who require it. It runs in a VPC peered to your existing agent infrastructure; the control plane (UI, ledger, billing) remains in Tarmac's cloud, with metadata flowing over a private link.
Fully air-gapped on-prem deployment is a 2027 question. Talk to us.
Tarmac 2.0 is the pivot of Tarmac 1.0 (a GPU brokerage) toward the real underserved gap: governing agent compute spend. The seed round funds the build, the SOC 2 program, and the first cohort of customers.
Jed is the founder. The company operates under Beaumont Consulting. The Q1 2026 hiring plan adds two founding engineers, a fractional CISO, and a solutions / security engineer — all senior. By end of Year 1 the team is eight; by end of Year 3, thirty-three. The first advisory board seats are open and being filled with finance-leader and infra-leader operators.
Phase 1 product (admit-to-settle, Agent Operations Dashboard, receipts) ships in Month 7. The Financial Console (statements, attribution, projection) follows in Months 10–12. Design partners are admitted in order from the waitlist; the first two are already in.
The 12-month milestone path: seed close → team of 8 → SOC 2 Type I → MVP live → first 2 design partners → 5 customers / $240K ARR → Series A ready.
Tarmac began as a GPU marketplace that helped agents find cheaper, more efficient GPU providers. The thesis proved weak: GPU access is already saturated (dozens of providers, free aggregators), and most agents consume token-priced inference APIs rather than raw GPU instances.
The genuinely underserved gap is not sourcing compute; it is governing it. Tarmac 2.0 is the layer that does — and reuses 1.0's strongest assets: the GPU price-aggregation work feeds Tarmac's live price signal, and the routing logic becomes the one-time step that assigns each agent a sufficient compute lane at onboarding.
Year 1: Phase 1 MVP, Phase 2 Financial Console, SOC 2 Type II, first ~20 customers, marketplace listings.
Year 2: GPU-rental lane adapter (training/fine-tuning), self-serve sandbox, regional residency for EU/UK, Series A.
Year 3: ISO/IEC 27001, APAC residency, on-prem appliance, deep allocation/ERP integrations, $8.6M ARR / 60 customers.
Email jed@beaumontconsulting.co. Every email Jed reads, Jed replies to — typically within a business day. The waitlist form is a faster path for non-urgent queries; founder calendar is for design-partner conversations and security reviews.
The FAQ is updated weekly. Most additions come from a single email that turned into the canonical answer for everyone who asked next. Send the awkward one — we promise we've thought about it.