Always-on AI employees for teams.
Built on browser-use. Designed for secure, cloud-native operations.
Website · Docs · Discord · Cloud
Gobii is the open-source platform for running durable autonomous agents in production. 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.
chat.mp4
Gobii agent demo in action
- 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
- Launch in 5 Minutes
- API Quick Start
- Deployment Paths
- Operational Profiles
- Production Use Cases
- FAQ
- Developer Workflow
- Docs and Deep Dives
- Contributing
- License and Trademarks
- 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.
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.
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
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]
| 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 |
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.
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/.
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]
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:
- Prerequisites: Docker Desktop (or compatible engine) with at least 12 GB RAM allocated.
- Clone the repo.
git clone https://github.com/gobii-ai/gobii-platform.git
cd gobii-platform- Start Gobii.
docker compose up --build- 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.
Optional runtime profiles:
docker compose --profile beat upfor scheduled trigger processing.docker compose --profile email upfor IMAP idlers and inbound email workflows.docker compose --profile obs upfor Flower + OTEL collector observability services.
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
}
}'| 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 |
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 + 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 |
- 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.
No. Gobii is based on browser-use, but adds persistent agent runtime behavior: schedule/event lifecycle, comms channels, webhooks, memory, orchestration, and operational controls.
Gobii can power individual workflows, but the architecture is tuned for team and business operations where agents stay active and integrate into production systems.
Yes. Gobii supports headed browser workflows and persistent profile handling for realistic web task execution.
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.
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.
Gobii integrates encrypted-at-rest secrets, proxy-aware outbound controls, and sandbox compute support with Kubernetes/gVisor backend options for stronger isolation.
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 --pool=threads --concurrency=4- 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
- Open issues and PRs are welcome.
- Follow existing project style and test conventions.
- Join the community on Discord.