How it works

One clear picture of BINA

BINA is a supply-intelligence agent for agencies. It reads the SSP platforms every night, turns that firehose of data into trustworthy answers, and lets your team act on deals — always behind a human approval chain. This page explains the architecture, the AI, the security, the database, and how new features ship safely to production.

Chat-firstMulti-tenant & firewalledToken-frugal AIHuman-approved actionsAgent-extendable
01

The system at a glance

Data flows up from the platforms into insight; actions flow down through a safety gate. The AI never touches raw data or acts on its own.

You — ask a question, or act on a deal
chat-first
AI brain — narrates insight, drafts proposals
Haiku routes · Sonnet composes
Metrics layer — the only path to numbers
pre-vetted, correct by construction
Insight engine — finds what changed (no AI)
deterministic statistics
Warehouse — nightly rollups
data through yesterday
Ingestion — nightly SSP sync
one platform failing never blocks the rest
SSP platforms — Index Exchange, Magnite, PubMatic, Xandr…
the source of the gold
Actions flow back down only through the approval gate — never automatically.
02

Three surfaces, one agent

Everything lives in one chat-first app. Ask a question, read what changed overnight, or work a client's deal book — the same engine powers all three.

Home

Chat — Question & Action

One prompt box, two modes. Question answers analytics and benchmarks with a chart, a table, and its provenance. Action drafts a guardrailed deal proposal — it never executes on its own.

  • Five daily suggestion chips
  • Answers cite n, window & k
  • History is saved and queryable
Intelligence

Nightly bites

“What changed while you slept.” Statement-first cards — the claim, the number, the n — precomputed overnight, so they render instantly with zero model cost at view time.

  • Rebuilt every night
  • Every bite carries its chart
  • A data-as-of stamp on each
Deals

The deal workspace

A per-client deal library synced from the platforms. Status pills, filters, CSV export, and an instant-look expander — everything through yesterday, nothing live, so numbers never flicker.

  • Live / waiting / paused
  • Spend, win-rate & fee drift
  • Row actions → approval chain
ConnectorsIndex Exchange ships first. Its deal-management endpoints are broken vendor-side, so proposals draft, approve, and queue as blocked-vendor — draining automatically once IX ships the fix. Xandr, Media.net and others plug in through one typed connector interface.
03

The AI brain, in four layers

A strong agent is more than a model. BINA is built on the four layers every capable AI agent needs — each doing one job well.

Your prompt
ModelRoutes the request
a cheap, fast model reads intent (Haiku)
Memory
history · cache
PlanningDecides the steps
one pass today · multi-step next
ToolsReads the metrics layer
the only path to numbers — correct by construction
Warehouse
precomputed · deterministic
ModelComposes the answer
the stronger model writes it (Sonnet)
Typed answer
chart + text + provenance — never raw HTML
ToolsIf it's an action: draft a proposal → approval gate → SSP connectors. Never automatic.

How one request flows through the brain — the four layers at work

Model
Built

The brain that reads & writes

A cheap, fast model (Haiku) reads every prompt and decides intent. A stronger model (Sonnet) composes the answer or drafts the deal. Spend is capped per client.

Memory
Built · deepening

What it remembers

Every prompt, answer, and action is logged — a product asset that feeds the daily suggestions. Precomputed nightly intelligence and an answer cache keep it fast and cheap.

Planning
Next

Breaking goals into steps

Today the agent answers in a single pass — the fastest, cheapest path. Multi-step investigation (“why did this deal change, and what should we do?”) is the next build.

Tools / Harness
Built

The hands & the body

The SSP connectors, the approval chain, the database firewall, and the scheduled jobs. This is what lets the agent actually read platforms and (safely) act on deals.

The golden rule: the AI never computes a number and never acts on its own. It reads figures that were calculated deterministically, and it can only propose actions — humans approve them.

04

Security — defense in depth

Every layer assumes the one above it could fail. A client can never see another client's data, and the AI can never move money on its own.

Tenant firewall at the databaseRLS

Each client is a separate tenant. Isolation is enforced by PostgreSQL Row-Level Security — not just app code. Even if application logic had a bug, the database itself refuses to return another tenant's rows. Proven by an automated cross-tenant test.

The AI can propose, never executeGuardrail

No write tool is ever exposed to the model. It drafts a proposal; deterministic code evaluates the rules; the action only runs after human sign-off. The agent can never mark its own action as approved.

Two-party approval, with undoApprovals

Operator sign-off is always required. Any change to a LIVE deal is two-party ping-and-approve — explicit client AND operator consent — a rule no envelope can override. Every executed action has a 10-minute undo window and an append-only audit trail.

Secrets never leave the vaultVault

Platform credentials live encrypted in Supabase Vault, decrypted only inside job code at the moment of use — never in logs, never in prompts, never in the browser.

Typed, sanitized renderingContracts

The model outputs structured data, never raw HTML — closing an entire class of injection risk. Every value is validated before it renders.

05

The database

One PostgreSQL database, hard-partitioned by tenant. Internal MCG users see every client; each external client sees only their own world.

Who's asking
Client A user
Client B user
MCG internal
The gate
Row-Level Security
every query is checked against the caller's identity — inside PostgreSQL, not just app code
What comes back
Client A → only Client A's rows
Client B → only Client B's rows
MCG internal → every client
Client A → Client B's rows

Every query is checked against the caller's identity — in the database itself

One database · hard-partitioned
Nexxen isolated
Digital Remedy isolated
Tatari isolated
StackAdapt isolated
ROW-LEVEL SECURITY · the firewall lives in the database

Internal MCG users see every client. Each external client is locked to their own tenant — a query for another client's rows returns nothing, enforced by the database itself.

What's stored
  • Deals & nightly metricssynced from the SSP platforms, through yesterday
  • Conversations & every prompt/answerthe queryable history and product-asset log
  • Actions, approvals & audit logappend-only; who did what, when, and why
  • Precomputed bites, chips & benchmarkscross-client benchmarks only where ≥3 clients contribute (k-anonymity)
  • Envelopes & settingswhat the agent may pre-authorize — managed as data, not code
  • Encrypted credentialsreferenced by name; the secret itself lives in the vault
06

Built to be cheap

Cost matters to MCG. Five compounding levers mean most answers barely touch the AI — and every client has a hard monthly ceiling.

01

Precompute nightly

Aggregates, benchmarks and bites are built once overnight — chat reads small tables, not the raw firehose.

02

Answer cache

A repeat question returns from cache, refreshing only the numbers — no model call at all.

03

Prompt caching

The stable system prompt is cached, so instructions cost a fraction after the first request.

04

Model routing

A cheap, fast model (Haiku) routes and classifies; the stronger model (Sonnet) only composes — never the other way around.

05

Per-tenant quota

Every client has a hard monthly ceiling: alert at 80%, graceful degrade to aggregates and Deals at 100%. No surprise bills.

GatewayModels are called through the Vercel AI Gateway — one key, provider fallback, and per-client cost observability, with no code change to swap a model.
07

How you contribute with Claude Code — safely

You can use your own Claude Code subscription to build features between our releases. Nothing you change reaches production until it passes the automated gate and our QA.

1You + Claude Code

Make changes on a feature branch, locally, with your own subscription.

2Open a pull request

Never straight to production — a branch and a PR, always.

3Automated gate (CI)

Typecheck · lint · boundaries · 40+ tests · build · browser QA. All must be green.

4Live preview

A private preview URL is built for that exact change to click through.

5Our QA review

A human on our side reviews it and runs the full browser QA against the preview.

6Merge → production

Only green + approved merges to main, which auto-deploys. Rollback is instant.

The rules travel with the repo

A CLAUDE.md file ships in the codebase. Every Claude Code session — yours or ours — automatically follows the same hard rules: never expose a write tool to the model, never weaken the tenant firewall, respect the module boundaries.

The gate is automatic & non-negotiable

Every pull request runs typecheck, lint, module-boundary checks, 40+ unit tests, a production build, and a full browser QA pass. Red means it cannot merge — no exceptions, no human override needed.

Production is one click from safe

Only a green, QA-approved change merges to the main branch, which auto-deploys to production. If anything looks wrong, rollback is instant.

08

Why this is a strong, high-level solution

Trustworthy by construction

Numbers are computed deterministically and the AI only narrates them — so it can't cite a wrong figure. Trust is the product.

Cheap to run

Nightly precompute, caching, and small-model routing mean most answers barely touch the AI. ~$0 to test; a small, capped bill in production.

Safe with real money

Real deal actions run only behind envelopes, human approval, undo, and a full audit trail — the hardest part, built first.

Built to grow with you

New behaviours are data and small modules, not rewrites — so you and Claude Code can extend it safely, fast, between our releases.