ARCHITECTURE & DEVELOPERS
Build on DRENTIR.
Every great operating system became great because developers built on it. DRENTIR is designed as a platform from day one: tooling for specialized agents, connectors to the software you already use, and APIs for programmatic control. If you build software, there will be a way in.
Developer APIs and SDKs are not public yet. This page documents the architecture direction and technical preview.
BUILDING BLOCKS
Three ways to build.
Different builders need different doors into the system.
01
Agents as primitives
Define specialized agents in code — their role, their tools, their data scope, their permission boundaries. Version them, review them, roll them back like code.
02
Connectors
Plug into the software your users already run: email, calendar, CRM, documents, messaging. One connector makes every agent smarter.
03
Open schemas
Plans, tasks, results and the audit trail share one documented schema. Anything you build speaks the same language as everything we build.
SYSTEM PLANES
Five planes, one system.
DRENTIR is organized as planes — each with a clear job, each crossing the others only through defined boundaries.
01
Interface plane
Where you meet DRENTIR: conversation, voice and the Command Center. Everything you see and say starts here.
02
Agent plane
Where work gets planned and coordinated: specialized agents, plans, orchestration. The reasoning layer of the system.
03
Tool plane
Where DRENTIR touches the world: connectors to email, calendar, CRM, documents, messaging, browser and files.
04
Model plane
Where thinking happens: local models for privacy and speed, cloud models for capability — routed per subtask.
05
Control plane
What keeps it yours: permissions, approvals, policies and the audit trail — crossing every other plane.
ARCHITECTURE
How a request travels.
One request crosses the planes top to bottom; the control plane watches every crossing.
You
A goal in plain language — spoken or typed.
Interface plane
Understands the request, manages the conversation.
Agent plane
Builds the plan, coordinates specialized agents.
Tool plane
Calls connectors: email, calendar, CRM, files, browser.
Model plane
Routes each subtask to the right model — local or cloud.
Control plane — spans every layer
Permissions, approvals, policies and the audit trail apply at every step.
EXECUTION CONTEXT
Everything an agent may do — declared up front.
Three sketches of the design direction: who the agent works for, what it is built from, and what it is never allowed to do.
context "weekly-review" { owner: maya@studio workspace: studio.ops permission: PREPARE # draft, never send data_scope: [mail.read, calendar.read] escalate { before: [send, spend] on_urgent: notify.owner }}manifest "triage-agent" { version: 0.3.1 runtime: drentir.agent/1 tools: [mail.read, crm.lookup] models: { default: local.qwen3, fallback: cloud.claude } limits { max_cost_per_day: 2.00 USD max_actions_per_run: 25 }}policy "outbound-comms" { deny: [send.email, send.sms] allow: [draft.email, draft.sms] require_approval: [spend.money, change.records] audit: everything # no silent actions}DIRECTION
Agents as code, permissions as code.
The shape we are designing toward: an agent is a small, reviewable definition — what it does, what it may touch, and where it must ask.
agent "triage" { on: inbox.new_message permission: PREPARE # draft only, never send tools: [mail.read, crm.lookup] escalate { before: send # always ask first on_urgent: notify.owner }}PRINCIPLES
Built the platform way.
Permissions from line one
Anything you build inherits the permission model — your agents can never outgrow the boundaries they are given.
Observable by default
Your agents write to the same audit trail as everything else. Debugging stops being guesswork.
Humans stay in the loop
Escalation is a primitive, not an afterthought: define where your agent must ask, and it will.
ROADMAP
What builders get first.
The platform opens up in stages. Early access members shape each one.
Agent definitions
Define and deploy agents through the sketch above. This is the design direction under active development right now.
Read API first
Programmatic access to plans, tasks, results and the audit trail — before anything can write.
Connector SDK
Build connectors others can install: email, calendar, CRM, documents, and beyond.
Write API and sandbox
Mutations and a safe test environment arrive after the read surface is solid.
QUESTIONS
Asked by builders.
Not yet. DRENTIR is a pre-MVP working prototype, and the API surface is being designed with input from prospective early users — not in isolation. Technical preview members get the first keys and help shape what the API becomes.
Planned. Typed SDKs will follow the read API, with agent definitions and the permission model as first-class citizens — so the code you write cannot outrun the boundaries you set.
Email and calendar — the delegation most people ask for — then CRM and messaging. The connector SDK will let the community fill the rest.
Join Early Access and tell us you build. Developer previews, design docs and the first keys go to early access members first.
Want to build on DRENTIR?
Join early access and tell us you build — developer previews go to members first.