Zendeploy turns autonomous agents into a workforce you can see and govern. Each agent you configure shows up as an avatar — with its own schedule, a running agenda of what it has done, and live ways to step in: chat with it, or open its desktop, its app, or its IDE. Work reaches your agents three ways — on demand from the console, from your communication channels, or on a schedule — and every action travels one governed path: authorized, routed, recorded, auditable, under your tenant's access policy. This page is where the platform is and where it is going; what is built, what is in build, and what is on the roadmap are marked honestly throughout.
Open the console and you see your agents the way you'd see a team — each one an avatar with a name, the department and role you gave it, its schedule, and a short agenda of its latest events. Nothing is hidden behind a queue you can't read. When you want to step in, you step in.
Each configured agent renders as an avatar carrying its name, department and role, its schedule, a status, and a short agenda of its latest events — what it did, when, and whether anything needs you. No polling, no opaque queue.
From any avatar you can talk to the agent directly, or open its environment when that environment supports a visitable workplace — a VNC view of its desktop, the web app it runs in, or its IDE. You are never locked out of what your agent is doing.
An agent is configured in a simple interface — you place it in your organization, choose the runtime that powers it, connect the channels it works through, and set when it runs. The choices you make here become the agent's authority: it acts only as the department and role you assigned, never more.
Configuration is a form, not a config file. The department and role you choose decide what the agent is allowed to do and which environment it runs in. The runtime decides which model powers it. The channels decide where its work comes from and goes. The schedule decides when.
Behind the fleet is a control plane built for an organization, not a hobby project. It is a set of modules — each an enterprise control surface scoped to your tenant's access policy (RBAC). Who can see a module, run an agent, open an environment, or read an audit trail is your decision, enforced by default-deny: if a rule doesn't allow it, it doesn't happen.
The intelligence behind each agent is a knowledge framework loaded into its working context — a hypertext of your operating knowledge drawn from documents, structured stores, and graphs. Agents reach it over a confidential, RBAC-screened connection, through both an API and a command-line channel, and only ever see the slice their role is cleared for. A human-browsable view of the same knowledge base is on the roadmap.
Work reaches your agents through three entry points — and whichever one fires, the same governed path runs underneath. Read the chart left to right: any trigger is authorized, routed, run, recorded, and surfaced for overwatch and audit. The legend names what each step does.
THREE WAYS WORK STARTS ONE GOVERNED PATH FOR ALL THREE
WebUI - on demand \
channels - incoming / outgoing )----> authorize ----> route ----> agent environment ----> durable record ----> overwatch + audit
schedule - recurring / one-time /
authorize ........... per-tenant RBAC, default-deny - who may run this action, and on whose behalf
route ............... department + role decide the environment; capacity is checked before anything runs
agent environment ... the agent loads your confidential, RBAC-screened knowledge framework, then works;
you can chat with it, open a VNC desktop, an in-environment app, or an IDE
durable record ...... event log (who was authorized, with what verdict and route) + inference log
(what the agent reasoned, called, and produced) - redacted, kept for later
overwatch + audit ... live fleet status and after-the-fact, per-tenant audit of every action