Connect the tools you already run.
Agentycs is built to slot into an existing estate rather than replace it: your identity provider, your dashboards, your agent tooling, your automation, your buckets. Every integration here uses a standard protocol, and there is no proprietary client to adopt.
What this page covers #
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
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
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
Identity and access #
People sign in with the identity they already have, and membership stays in step with your directory automatically. Machine access is separate, explicit and revocable.
- OIDC federation
- Your own identity provider per workspace: authorize, callback and refresh, so nobody manages a second set of credentials.
- Directory sync
- Users provisioned and de-provisioned over SCIM, Entra or Google, so joiners and leavers propagate on their own.
- Personal access tokens
- Long-lived programmatic credentials stored only as hashes, exchanged for short-lived bearer tokens, never carried in a URL, denied immediately on revocation.
- Capability tokens
- Signed, short-lived credentials for scoped machine-to-machine calls, verifiable against a published JWKS.
Nothing here only works if the rest of your stack is ours. That is the test we hold ourselves to.
Analytics and business intelligence #
Point your existing dashboard or notebook stack at the lakehouse over the PostgreSQL wire protocol, or at Arrow Flight SQL when the volume justifies a columnar path. The tool does not need to know it is not talking to a database.
$ 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.
AI tooling and agents #
Existing OpenAI-compatible clients, agent frameworks and editors reach your own models through the /v1 API. MCP clients reach your applications' operations as tools, with the same per-operation checks as any other caller.
- OpenAI-compatible SDKs and anything built on them, unchanged
- MCP clients, with app scope and per-tool capability gating
- Sovereign, self-hosted web search for agents that need fresh information
- Grounded retrieval over your own documents and records
Automation and eventing #
Drive the platform from whatever already orchestrates your work. Application operations are available over REST, subscriptions arrive over server-sent events, and long-running processes can be handed to durable workflows that survive restarts.
curl https://agentycs.example.com/api/apps/inspections/open_findings \
-H "Authorization: Bearer $AGENTYCS_API_TOKEN" \
-H "Content-Type: application/json" \
-d '{"site_id": "FAW-014"}' Authenticated application traffic lives under /api/apps/{app}/. Public routes an app chooses to expose live under /api/public/apps/{app}/. The operation name is the one the application declared.
curl -N https://agentycs.example.com/api/apps/inspections/open_findings \
-H "Authorization: Bearer $AGENTYCS_API_TOKEN" \
-H "Accept: text/event-stream"
event: snapshot
data: {"rows": [{"site": "Fawley", "open_findings": 12}]}
event: diff
data: {"changed": [{"site": "Fawley", "open_findings": 11}]} One operation, two reading modes. Ask for an event stream and you get the current answer once, then only what changes. The same subscription is available over the realtime socket.
Storage and infrastructure #
Object storage is S3-compatible in both directions: bring your own bucket as a backing store, or consume the platform's sovereign store with the tooling you already have.
- S3-compatible object storage, whether the bucket is yours or the platform's
- Kubernetes underneath, with the platform reconciled from declared custom resources
- Your existing GitOps practice still applies: desired state in git, converged by the cluster
- Metrics, traces and alerts exposed for the monitoring stack you already run
Keep going #
Connectors
Document sources synced incrementally, and external databases registered as native tables.
Open →OpenAI-compatible API
A drop-in /v1 API in front of your own models, reachable from the clients you already run.
Open →Trust and security
How identity, isolation, supply-chain provenance and audit fit together into an assurance position.
Open →