Build against interfaces you already know.
Agentycs puts your models, your data and your applications behind the protocols your tools already speak. Point an existing SDK, driver, dashboard or agent at your own instance and nothing in the client has to change.
Your first call #
Two of the most common starting points: inference through an OpenAI-compatible client, and analytics straight over the lakehouse. Both use credentials you issue yourself.
Change the base URL. That is the migration.
import os
from openai import OpenAI
client = OpenAI(
base_url="https://agentycs.example.com/v1",
api_key=os.environ["AGENTYCS_API_TOKEN"],
)
stream = client.chat.completions.create(
model="chat-large",
messages=[
{"role": "user", "content": "Which sites are behind on inspections?"},
],
stream=True,
)
for chunk in stream:
print(chunk.choices[0].delta.content or "", end="")Two lines change: the base URL becomes your instance, and the key becomes a token you minted. The model name is a deployment from your own catalogue, not a vendor's.
$ psql "postgresql://[email protected]:5432/operations"
=> SELECT site,
count(*) AS open_findings
FROM inspections
JOIN findings USING (inspection_id)
WHERE findings.status = 'open'
GROUP BY site
ORDER BY open_findings DESC
LIMIT 20;Documents, structured records and synced external systems are all queryable as tables. Your dashboard tool connects with the same string.
What you build against #
Eight surfaces cover everything a customer's code touches. Each one is a standard protocol or a declarative contract, not a bespoke client library you have to adopt. The architecture page names the same eight, in the same order, because they are the same list.
OpenAI-compatible API
Point the SDKs and tools you already use at your own private models.
- Existing OpenAI SDKs, agent frameworks and editors work unchanged
- Self-issued API tokens, revocable immediately
PostgreSQL wire protocol
Query the lakehouse with any Postgres client or BI tool, as if it were Postgres.
- Standard drivers and existing dashboards connect directly
- Analytics run over the live lakehouse, with no warehouse to load
Arrow Flight SQL
Columnar, high-throughput analytical access for data tools.
- Results stream as Arrow record batches
- Built for dataframe libraries and analytical engines
Graph queries
Traverse tabular data as a connected graph, without maintaining a graph database.
- ISO GQL, Bolt-compatible clients
- Relationships inferred from the live schema
REST, WebSocket and MCP
Every application exposed identically over all three, with live updates.
- Generated REST facade over every query and mutation
- Live queries: snapshot, then diffs, as data changes
Application Framework
Declare an application and the platform generates, signs and runs it.
- Typed Python SDK, visual blocks, browser IDE or agent-authored
- Production blocks with loading, empty and error states built in
Connectors and federation
Sync the systems your teams already use, or query them where they are.
- Incremental, per-tenant sync from the usual document sources
- PDF layout, tables, figures and OCR handled on the way in
Identity and tokens
Your identity provider, your directory, your credentials, one authorisation decision.
- OIDC federation per tenant: authorize, callback, refresh
- Directory sync over SCIM, Entra or Google
Where teams usually start #
Four routes in. None of them requires the others first, and all four end up on the same platform.
-
Call a model #
Serve open models on your own accelerators and reach them through a familiar interface, with policy deciding what may run where.
- Import an open model into your private hub, once
- Deploy it; placement and numeric format are chosen for your hardware
- Issue a token and point your existing client at /v1
-
Query your data #
Bring documents and records into one lakehouse, or leave systems of record where they are and federate them, then query everything through one engine.
- Sync document sources, or register an external database as tables
- Query over the PostgreSQL wire protocol, Arrow Flight SQL or graph
- Rely on the same row filters and column masks on every path
-
Build an application #
Declare what an application does and let the platform generate the frontend, the API surfaces, the packaging and the rollout.
- Declare pages, blocks, queries, workflows and capabilities
- The platform emits the bundle and a signed, attested package
- Deploy it as a resource, roll out by canary, revert in seconds
-
Wire up an agent #
Give an agent grounded retrieval and real tools, with every call passing the same permission check as a human's request would.
- Expose an application's operations as Model Context Protocol tools
- Ground answers in hybrid search over your own data
- Audit every privileged action back to the identity behind it
True on every path #
The protocol you choose changes the ergonomics, never the rules. These hold whether a request arrives as SQL, REST, a socket frame or a tool call.
One authorisation decision #
Role, capability and attribute rules resolve through a single audited decision, so no protocol can become a softer way in.
Server-derived tenancy #
Which workspace a request belongs to comes from validated session or token state, never from a header, hostname or client hint.
Filtering during execution #
Row filters, column masks and deny decisions are part of query execution, not a layer a direct driver connection can step around.
Bounded by default #
Queries are read-only unless declared otherwise, with mandatory limits and a cost ceiling, generated or hand-written.
Live rather than polled #
Every committed change is published as a change feed, so subscriptions receive a snapshot and then diffs instead of re-reading.
Recorded and auditable #
Data access and privileged actions land in a redacted audit record correlated to the identity and the query behind them.
What sits underneath #
The interfaces are the top of five layers. Everything below them is declared as Kubernetes resources and reconciled by one control plane, which is why the same platform runs in a managed cloud, in your own datacentre, or on a single disconnected machine carried to the site in a backpack.
Interfaces
What your code talks to. Standard protocols in front of everything below, so existing clients, drivers and agents connect unchanged. These are the same eight surfaces the developer overview names, in the same order.
Applications
First-party products and the framework you build your own with, sharing one workspace shell, navigation and design system.
Data, intelligence and delivery
The three engines that make the platform worth building on: where data lives and is understood, how models are served, and how software is built.
Platform foundation
The always-on substrate every application runs on. Routing, identity, live data, durable workflows, the database and observability.
Infrastructure
Hardware, Kubernetes, storage and network. The same platform sits on all of it, which is what makes managed, private, on-premises, edge and air-gapped the same product.
You do not need any of it to build here. It is worth knowing they are one system, because that is what keeps a permission decision, a change feed or an audit record meaning the same thing whichever interface you came in through. Read the architecture
Where to go next #
Architecture
How the interfaces, the lakehouse, the model plane and the control plane sit on top of each other.
Open →Deployment models
Managed, private cloud, on-premises, air-gapped, edge and multi-site, with the same platform in each.
Open →Trust and security
Isolation, supply-chain provenance, sovereignty and the assurance material behind them.
Open →Resources
Guides, references and the material an evaluation or an implementation actually needs.
Open →