Skip to main content

  1. Agentycs
  2. Developers
  3. Integrations

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.

Query the lakehouse with psql · SQL
$ 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.

Call an application operation over REST · Shell
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.

Subscribe to the same operation over server-sent events · Shell
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