Platform / Shape-typed

Sections, not blobs.

Most data APIs answer a narrow question with a wide document. An agent pays for the whole thing in the one currency it cannot spare — context. swarmsDB responds in typed sections an agent can project, so the request decides what crosses the wire, not the upstream.
select=id,doi,title,cited_by_count
  1. 01

    Ask for a section

    Name the fields you actually read. The request carries a projection — the shape you want back — not a hope that the payload is small.

    select=id,doi,title,cited_by_count
  2. 02

    Only those fields cross the wire

    The upstream response is projected to the section server-side. Four fields asked for, four fields returned — the other forty thousand tokens never enter your context window.

    4 fields in · 4 fields out
  3. 03

    Oversized payloads degrade, they do not flood

    When a response is too large to be useful whole, it comes back as a schema plus a preview rather than as a wall of JSON. An agent can see the shape and ask again, instead of losing its window to one call.

    schema + preview, not a flood

Why it matters

The context window is the budget.

On requests that project a section, payloads come back 76% smaller (4.2×). The largest single live reduction we have measured turned 8,457,367 characters into 1,508 — the difference between an agent reading one source and reading several within the same window.

See the measured proof

More in this area

Keyless OAuth connectorsA third party connects by grant. No API key changes hands.Governed autonomyOrg budgets stop overspend on the serving path — a real 402, not a report.Earned freshnessCache TTL justified per endpoint, never assumed from a header.

Point one agent at it.

Connect over MCP or REST. If your agents read more than one source, the context bill is the first thing you will see move.

Start building See how it works

Measured on our own agent-swarm workload. swarmsDB is battle-tested, not yet widely adopted — external traction is the next milestone.