Pangram verdict · v3.3
We believe this text is mainly AI, with some human-written content.
AI likelihood · overall
AIArticle text · 736 words · 6 segments analyzed
Multi-agent workspace manager built on Pi. Orchestrates AI coding agents — similar to Claude Code or OpenClaw — with tick-based scheduling, priority queues, inbox IPC, cross-agent file access, watchdog monitoring, proactive cron jobs, optional Docker sandbox isolation, and declarative YAML configuration. agent-office.mp4 Get Started Try one of these examples to get up and running quickly. Set env vars in the project root .env (not inside Docker — the host forwards them to containers).
Basic team — PM, coder, and reviewer (uses GitHub Copilot OAuth, no API keys): pnpm install cp -r examples/basic-team/ ~/.agent-office/offices/basic-team/ pnpm dev oauth login github-copilot --office basic-team pnpm dev start --office basic-team --sandbox docker OpenServ team — idea scout, team lead, agent dev, and token launcher: pnpm install cp .env.example .env mkdir -p ~/.agent-office/offices/openserv-team cp examples/openserv-team/office.yaml ~/.agent-office/offices/openserv-team/office.yaml pnpm dev start --office openserv-team --sandbox docker OPENAI_API_KEY= WALLET_PRIVATE_KEY= # EVM wallet key for openserv-labs/skills agents Feature team — task-driven development with Kanban board: cp -r examples/feature-team/ ~/.agent-office/offices/feature-team/ pnpm dev start --office feature-team See examples/ for more details — each has a README describing the setup.
Table of Contents Architecture Quick Start OAuth Authentication Supported Providers CLI Commands Using OAuth in office.yaml Web UI Auth Selector Multi-Office Architecture Creating an Office Office Configuration Heartbeat Permissions Tool Policy Hierarchy Auto-Sync Reload Cron Jobs Office-Level Cron Agent Cron Tools Task Management Migration from agents.yaml Sandbox Modes In-Process Mode Docker Sandbox Mode Commands Hire Options CLI Flags Execution Surfaces REST API Endpoints Agent Tools list_agents message_agent message_user post_channel read_agent_file authenticated_fetch cron_add cron_remove cron_list read_skill skill_search skill_install skill_remove skill_create task_create task_update task_list task_get task_delete Tool Architecture Prompt System Concepts Tick-Based Scheduler Priority Levels Workspace Sandboxing Skills Watchdog Message Persistence Prompt Inspection Cost Tracking Web UI End-to-End Examples Project Structure Dependencies Development Architecture graph TD YAML[office.yaml] --> WS CLI[CLI + Web UI] --> WS[Workspace] WS --> SCH[Scheduler\ntick loop] WS --> BUS[MessageBus\ninboxes] WS --> WD[Watchdog\nheartbeat] WS --> CRON[CronService\nscheduled jobs] WS --> TS[TaskService\nKanban board] WS -->|in-process| A[Agent A\nPi · tools · skills] WS -->|in-process| B[Agent B\nPi · tools · skills] WS -->|Docker sandbox| HA[Host API\nHTTP :13000] HA <-->|HTTP| SA[Sandbox A\nDocker · Pi · proxy tools] HA <-->|HTTP| SB[Sandbox B\nDocker · Pi · proxy tools] BUS --> A BUS --> B BUS --> HA Loading Core flow: office.yaml (auto-spawn) / CLI / Web UI / Cron / Agent cron tools / Task notifications -> Workspace -> Scheduler tick -> drain inbox -> dispatch to Pi Agent -> agent runs tools -> response streamed to UI. Each agent is a full Pi coding agent with its own filesystem workspace, skills, and injected tools (message_user, post_channel, message_agent, list_agents, read_agent_file, authenticated_fetch, cron_add, cron_remove, cron_list, task_create, task_update, task_list, task_get, task_delete, read_skill, skill_search, skill_install, skill_remove, skill_create). The scheduler runs a tick loop that serves agents by priority, one message per tick per agent, non-blocking. Agents can run in-process (default) or inside Docker containers for full process-level isolation. Quick Start pnpm install # Configure .env cp .env.example .env # then fill in your keys # Create an office pnpm dev office create my-team # Start (Web UI auto-starts) pnpm dev start --office my-team # Start with Docker sandbox isolation pnpm dev start --office my-team --sandbox docker Create a .env file with your provider API keys. Each model requires its corresponding provider key: # Model API Keys (required for agents using these models) OPENAI_API_KEY=sk-... # For OpenAI models (gpt-4o, etc.) ANTHROPIC_API_KEY=sk-... # For Anthropic models (Claude, etc.) GEMINI_API_KEY=... # For Google Gemini models XAI_API_KEY=...
# For xAI Grok models # Optional: Custom secret refs for office.yaml agents # MY_GH_TOKEN=ghp_... # Host env vars for authenticated_fetch secrets Authentication: Each model needs credentials.
You can use either API keys (.env) or OAuth: API keys — set in .env (e.g. OPENAI_API_KEY=sk-...). Required when the model's provider has no OAuth credentials. OAuth — authenticate via provider CLIs before starting. OAuth tokens auto-refresh and don't require .env keys.
# Option A: API keys in .env echo "ANTHROPIC_API_KEY=sk-..." >> .env # Option B: OAuth login (requires provider CLI installed) pnpm dev oauth login anthropic --office my-team pnpm dev oauth list --office my-team When both OAuth credentials and an API key exist for a provider, you can switch between them per-agent in the Web UI. See OAuth Authentication for details. See the Dynamic Model Discovery section below for how to browse available models and their requirements in the Web UI. OAuth Authentication As an alternative to API keys in .env, agents can authenticate with model providers via OAuth.