README.md
June 29, 2026 · View on GitHub
Gobii
AI coworkers for teams with real work to do.
This repository contains the open-source Gobii Platform for self-hosting and development.
Looking for the hosted product? Start at Gobii AI coworkers.
Official Website · Docs · Discord · Gobii Cloud
Gobii is an AI coworker platform for running durable autonomous agents in production. The hosted Gobii product is available at gobii.ai; this repository contains the open-source platform for self-hosted deployments and development. Each agent can run continuously, wake from schedules and events, use real browsers, call external systems, and coordinate with other agents. Each agent can also be contacted like an AI coworker: assign it an identity, email or text it, and it keeps working 24/7.
If you are optimizing for local-first personal assistant UX on a single device, there are excellent projects for that. Gobii is optimized for a different problem: reliable, secure, always-on agent operations for teams and businesses.
Gobii agent demo in action
Quick Install
Most users looking for Gobii Cloud should start at gobii.ai. Use this install path when you want to self-host or develop against the open-source Gobii Platform.
- Prerequisites: Docker Desktop (or compatible engine) with at least 12 GB RAM allocated.
- Run the hosted installer.
curl -fsSL https://gobii.ai/install.sh | bash
Supported installer inputs:
GOBII_INSTALL_DIR: target repo checkout directory. Defaults to~/gobii-platform.GOBII_REF: Git ref override. Defaults to the latest tagged release.
Stable installer endpoint: https://gobii.ai/install.sh
Alternatively, use the manual path:
git clone https://github.com/gobii-ai/gobii-platform.git
cd gobii-platform
docker compose up --build
For Docker-based products, the standard pattern is to validate Docker and Compose rather than install Docker for you. This installer is a thin wrapper around the existing compose.yaml bootstrap flow.
- Open Gobii at http://localhost:8000 and complete setup.
- Create your admin account.
- Choose model providers (OpenAI, OpenRouter, Anthropic, Fireworks, or custom endpoint).
- Add API keys and preferred model configuration.
- Create your first always-on agent.
Table of Contents
- Quick Install
- Why Teams Choose Gobii
- Gobii vs OpenClaw (Production Lens)
- AI Coworker Interaction Model
- How Gobii Works
- Always-On Runtime: Schedule + Event Triggers
- Production Browser Runtime
- Identity, Channels, and Agent-to-Agent
- Security Posture
- API Quick Start
- Deployment Paths
- Operational Profiles
- Production Use Cases
- FAQ
- Developer Workflow
- Docs and Deep Dives
- Contributing
- License and Trademarks
Why Teams Choose Gobii
- Always-on by default: per-agent schedule state plus durable event processing.
- Identity-bearing agents: each agent can have its own email address and SMS phone number, so teams can contact it directly.
- Native agent-to-agent messaging: linked agents can coordinate directly.
- Webhook-native integration model: inbound webhooks wake agents; outbound webhooks are first-class agent actions.
- Based on browser-use: keeps
/api/v1/tasks/browser-use/compatibility while adding platform-level runtime controls. - SQLite-native operational memory: structured state substrate for long-running tool workflows.
- Real browser operations: headed execution, persistent profile handling, and proxy-aware routing.
- Security-first controls: encrypted-at-rest secrets, proxy-governed egress, and Kubernetes sandbox compute support.
Gobii vs OpenClaw (Production Lens)
OpenClaw is excellent software, especially for local-first personal assistant workflows and broad channel coverage. Gobii is optimized for a different target: cloud-native, secure, always-on agent operations for teams.
| Dimension | Gobii | OpenClaw |
|---|---|---|
| Primary deployment model | Cloud-native autonomous agent runtime (self-hosted or managed) | Local-first gateway and personal assistant runtime |
| Always-on behavior | Per-agent schedule + durable event queue continuity | Heartbeat and cron/wakeup session patterns |
| Webhook model | Inbound triggers plus outbound agent webhook actions in one lifecycle | Strong gateway ingress hooks and wake/agent webhook routes |
| Channel strategy | Fewer core channels with deeper lifecycle integration | Wider channel surface with intentionally thinner per-channel depth |
| Agent identity | Endpoint-addressable agent identities (email/SMS/web) | Workspace/session identity model |
| Human interaction model | Contact each agent directly through its own endpoint like an AI coworker | Primarily session/workspace-oriented assistant interactions |
| Agent coordination | Native agent-to-agent messaging | Orchestrator/subagent flows |
| Memory substrate | SQLite-native operational state | Markdown-first memory with optional vector acceleration |
| Browser runtime | Headed execution, persistent profiles, proxy-aware routing, distributed-worker friendly | Headed execution, persistent local profiles, strong local operator UX |
| Security defaults | Encrypted-at-rest secrets, proxy-governed egress, sandbox compute, Kubernetes/gVisor support | Local-first by design, sandboxing available but deployment-dependent |
| Best fit | Production team automation with governed runtime controls | Personal/local assistant workflows and channel breadth |
If your priority is secure, governed, always-on production execution in cloud or hybrid environments, Gobii is purpose-built for that.
AI Coworker Interaction Model
Gobii agents are designed to behave like AI coworkers, not disposable one-off tasks. You can email or text them directly, they wake from those events, execute work, and reply with context-aware follow-through.
sequenceDiagram
participant U as You / Team
participant E as Agent Email/SMS Endpoint
participant Q as Per-Agent Event Queue
participant A as Always-On Gobii Agent
participant T as Browser/Tools/APIs
U->>E: Send message to the agent
E->>Q: Inbound event is queued
Q->>A: Wake agent with full context
A->>T: Execute tasks and gather outputs
T-->>A: Results, files, and state updates
A-->>U: Reply with outcome and next steps
A->>Q: Stay active for follow-up events
How Gobii Works
flowchart LR
A[External Triggers\nSMS · Email · Webhook · API] --> B[Per-Agent Durable Queue]
C[Schedule / Cron] --> B
B --> D[Persistent Agent Runtime]
D --> E[Tools Layer]
E --> E1[Browser Automation\nheaded + profile-aware]
E --> E2[SQLite State\nstructured memory tables]
E --> E3[Outbound Integrations\nwebhooks + HTTP]
E --> E4[Agent-to-Agent\npeer messaging]
D --> F[Comms Replies\nSMS · Email · Web]
D --> G[Files + Reports + Artifacts]
Gobii Focus vs Typical Personal Assistant Stacks
| Area | Gobii focus |
|---|---|
| Runtime model | Long-lived schedule + event lifecycle |
| Primary operator | Teams and organizations |
| Agent identity | Addressable communication endpoints |
| Orchestration | Always-on processing + native A2A |
| Browser workload shape | Production tasks with persisted state |
| Security posture | Controlled egress, encrypted secrets, sandbox compute |
Always-On Runtime: Schedule + Event Triggers
Gobii agents are built to stay active over time, not just respond in isolated turns.
sequenceDiagram
participant S as Scheduler
participant Q as Agent Event Queue
participant R as Agent Runtime
participant T as Tools
participant C as Channels / Integrations
S->>Q: enqueue cron trigger
C->>Q: enqueue inbound event\n(email/sms/webhook/api)
Q->>R: process next event for agent
R->>T: execute required actions
T-->>R: outputs + state updates
R->>C: outbound reply / webhook / follow-up
R->>Q: continue or sleep
This gives you continuity for real workflows: queued work, retries, deferred actions, and predictable wake/sleep behavior.
Production Browser Runtime
Gobii is based on browser-use and adds production runtime behavior around it.
- Headed browser support for realistic web workflows.
- Persistent browser profile handling for long-running agents.
- Proxy-aware browser and HTTP task routing for controlled egress paths.
- Task-level API compatibility via
/api/v1/tasks/browser-use/.
Identity, Channels, and Agent-to-Agent
Gobii treats agents as operational entities, not just prompt sessions. When channels are enabled, each agent can be assigned identity endpoints and contacted directly like an AI coworker.
- Agents can own communication endpoints (email, SMS, web).
- Managed deployments support first-party agent identities like
first.last@my.gobii.ai. - Inbound email/SMS/web events can wake agents and route into the same runtime lifecycle.
- Agents can directly message linked peer agents for native coordination.
flowchart LR
U[Team member] --> E[Agent email or SMS endpoint]
E --> A[Assigned always-on Gobii agent]
A <--> P[Peer Gobii agent]
A --> R[Reply back to human channel]
Security Posture
Gobii's architecture is built for production guardrails.
- Encrypted secrets integrated into agent tooling.
- Proxy-governed outbound access with health-aware selection and dedicated proxy inventory support.
- Sandboxed compute support for isolated tool execution.
- Kubernetes backend support with gVisor runtime-class integration in sandbox compute paths.
For sandbox compute design references:
The sandbox compute server now lives in this monorepo under sandbox_server/, with its own Dockerfile, tests, and image workflows.
API Quick Start
curl --no-buffer \
-H "X-Api-Key: $GOBII_API_KEY" \
-H "Content-Type: application/json" \
-X POST http://localhost:8000/api/v1/tasks/browser-use/ \
-d '{
"prompt": "Visit https://news.ycombinator.com and return the top headline",
"wait": 60,
"output_schema": {
"type": "object",
"properties": {
"headline": {"type": "string"}
},
"required": ["headline"],
"additionalProperties": false
}
}'
Deployment Paths
| Self-host (this repo) | Gobii Cloud (managed) |
|---|---|
| MIT-licensed core on your own infrastructure | Managed Gobii deployment and operations |
| Full runtime/networking/integration control | Governed releases and managed scaling |
| Best for source-level customization | Best for faster production rollout |
Operational Profiles
Gobii keeps the default boot path simple, then lets you add worker roles as needed.
| Profile | Command | What it adds |
|---|---|---|
| Core | docker compose up --build | App server + default worker + interactive worker + Redis + Postgres + migrations/bootstrap |
| Scheduler | docker compose --profile beat up | Celery beat + schedule sync for cron/event timing |
| Email listeners | docker compose --profile email up | IMAP idlers for inbound email automation |
| Observability | docker compose --profile obs up | Flower + OTEL collector services |
The default worker consumes celery and celery.single_instance. The interactive worker consumes agent_interactive and is required for low-latency console/web chat replies; keep at least one interactive worker running anywhere web chat is enabled.
Production Use Cases
- Revenue ops agents: monitor inboxes and web systems continuously, update records, and send structured summaries.
- Recruiting ops agents: source candidates, enrich profiles, and coordinate outbound messaging from persistent workflows.
- Support and success agents: triage inbound channels, execute browser-backed actions, and escalate with full state continuity.
- Back-office automation: run long-lived, trigger-driven workflows that need durable memory and secure credentials handling.
FAQ
Is Gobii just a UI around browser-use?
No. Gobii is based on browser-use, but adds persistent agent runtime behavior: schedule/event lifecycle, comms channels, webhooks, memory, orchestration, and operational controls.
Is Gobii built for personal assistant usage?
Gobii can power individual workflows, but the architecture is tuned for team and business operations where agents stay active and integrate into production systems.
Does Gobii support headed browsers?
Yes. Gobii supports headed browser workflows and persistent profile handling for realistic web task execution.
Can each agent be contacted directly like a coworker?
Yes. With channels configured, each agent can be assigned its own endpoint identity (email and/or SMS), so your team can interact with it directly and asynchronously.
What does “always-on” mean here?
Agents can wake from schedules and external events (email/SMS/webhooks/API), process durable queued work, and continue across turns instead of resetting every interaction.
What is the security model?
Gobii integrates encrypted-at-rest secrets, proxy-aware outbound controls, and sandbox compute support with Kubernetes/gVisor backend options for stronger isolation.
Developer Workflow
Use DEVELOPMENT.md for the complete local setup and iteration flow.
Typical loop:
# backing services
docker compose -f docker-compose.dev.yaml up
# app server
uv run uvicorn config.asgi:application --reload --host 0.0.0.0 --port 8000
# workers (macOS-safe config)
uv run celery -A config worker -l info -Q celery,celery.single_instance --pool=threads --concurrency=4
uv run celery -A config worker -l info -Q agent_interactive --pool=threads --concurrency=1 --prefetch-multiplier=1
Docs and Deep Dives
- Getting started: Introduction
- Developer foundations: Developer Basics
- Agent API: Agents
- Browser task execution: Tasks
- Structured outputs: Structured Data
- Event ingress and automation: Webhooks
- REST reference: API Reference
- Self-hosting: Self-Hosted Deployment Overview
- Concepts: Agents, Dedicated IPs
- Advanced integrations: MCP Servers
- Local sandbox design docs: docs/design
Contributing
- Open issues and PRs are welcome.
- Follow existing project style and test conventions.
- Join the community on Discord.