A REST API and an SDK to build on TAO.
Extend the operating layer with your own apps. Reach your tasks, contacts, and workflows over a versioned REST API, and ship full modules with the TAO SDK — declare actions, surface cards, and connect new services into the same shell your team works in. API keys are scoped per workspace and issued when beta access is granted.
Two ways to build
There are two ways to reach into TAO. Use the REST API when you want to push and pull state between TAO and your own systems. Use the SDK when you want to ship a full module — a new feature or a new integration — that lives inside the operating layer alongside the first-party ones.
- REST API — read and write tasks, contacts, and workflows from anywhere.
- SDK — ship modules that add actions, cards, and integrations to TAO itself.
- Same platform, same controls: every call is scoped, credentialed, and audited.
The REST API
A versioned, documented REST API at api.theartificialorganisation.com. Keys are scoped so you can issue a narrow credential for exactly the integration you are building — no omnibus admin keys.
- Scopes per key: tasks.read, tasks.write, workflows.run, contacts.read, contacts.write.
- Rotate keys without downtime; sandbox keys are separate from production.
- Every API call is recorded in an audit log you can query from your TAO admin.
The SDK: build a module
A module is a coherent unit of feature with its own manifest, services, and frontend surfaces. It declares what it offers — actions, triggers, cards, Andy suggestions, entity types — in a manifest, and the base layer reads that manifest to render, route, and validate at runtime. First-party features (email, calendar, tasks, workflows) and third-party integrations (Notion, Current RMS, Xero, Slack) follow the exact same shape.
- Declare actions once; they appear to Andy, on voice, and in workflows.
- Wrap an external service and bring its data into the same shared record.
- Surface contextual cards and suggestions without touching base-layer code.
Safe by construction
The SDK is a boundary, not a convenience wrapper. Cross-module calls carry a credential and are logged, so no module can quietly read another tenant's data. Model calls route through one policy layer, knowledge writes are audited, and every multi-tenant table is isolated at the database level.
- Tenant isolation enforced in the database — not just in code.
- Every cross-module and model call is credentialed and audited.
- Andy never acts invisibly: writes a module proposes still pass through approval.
For technical readers — a module manifest
# backend/app/modules/hello/manifest.py
from app.sdk.manifest import (
ModuleManifest, ActionSpec, TriggerSpec, CardRendererSpec,
)
from .schemas import HelloGreetInput, HelloGreetOutput
manifest = ModuleManifest(
module_name="hello",
version=1,
description="Greets a person. Smallest possible module.",
actions=[
ActionSpec(
name="hello.greet",
input_schema=HelloGreetInput,
output_schema=HelloGreetOutput,
voice_eligible=True,
andy_eligible=True,
workflow_eligible=True,
description="Greets a person by name.",
),
],
triggers=[
TriggerSpec(
name="hello.greeted",
payload_schema=HelloGreetedPayload,
description="Fires after someone is greeted.",
),
],
card_renderers=[
CardRendererSpec(
surface="andy",
for_action="hello.greet",
renderer_id="hello-greet-andy",
schema=HelloGreetCard,
version="1",
),
],
)What you do not need to build
If your goal is to help day-to-day operators, you probably do not need to write any code at all. Andy and TAO Pilot already cover most of what teams reach for custom scripts to do. The API and SDK are for when you want to connect a new tool or push and pull state between TAO and your own systems.
Want to see this running on the apps you already use? Apply for the beta, or tell us what your team is trying to run from one place.