Every agent on your team,
one hub.
Members connect their own agents — Codex, Claude Code, Cursor or any MCP client — to the team's knowledge, files, projects and data, cut to their own permissions. Every write is recorded in their name, every paid call is metered, and Sprouty, the built-in assistant, uses the same tools — self-hosted, one process.
A member asks about the home-office stipend. The agent searches the team knowledge base, answers with citations, and the trace shows every tool call it made.
The idea
The agent is the product — not a feature bolted on the side.
Most AI tools stop at helping one person. The moment a team needs them, the hard parts are missing: who may see what, who approved what, and a record of what happened. Greenhouse is that missing part — the foundation an agent sits on, not another clever agent.
The tools your team uses in chat are the same tools you hand to Claude or Cursor. Adding a capability is writing one file.
Product tour
One place to work. The agent is in all of it.
The tool layer
One definition. Three entry points.
Declare a tool once with defineTool and add one line to the registry. It appears everywhere — automatically. No three separate lists drifting apart.
export const myTool = defineTool({ meta: { id: 'my_tool', brief: 'one-line summary', category: 'team', surface: { proxy: 'read', // read | write | none mcp: 'knowledge', // MCP resource group }, }, kind: 'static', create: (ctx) => tool({ /* … */ }), });
one tool = one file
The shared tool layer
Team chat
members, in-app
Agent API
/api/agent
MCP server
Claude · Cursor
Permissions only narrow, never widen — every surface is a subset of the user's own access.
Generative UI
Messages aren't just text.
When an answer carries a table, a chart or something to approve, the chat turns it into the real thing — sortable tables, charts, file cards, buttons. The agent only writes text; the interface decides how it looks.
The buttons work: a click answers the step the agent paused on, and it carries on.
- Sortable, searchable data tables with CSV export
- Charts — bar, line, pie, radar
- Confirm buttons that resume the agent
- Citations, record peeks, file & preview cards
Trust boundary
Safe to point at your whole org.
Permissions live in one place, and they only ever take away — never add. That is what makes it safe to open your company's tools to an outside agent.
Only narrow, never widen
An agent gets a subset of its user's permissions — it can never gain a capability the user doesn't have.
Writes need a human
Mutating actions are deny-by-default. Every write is confirm-gated and logged to an audit trail.
Fail-closed by design
No signing key, no encryption key? The server refuses to start. No "forgot to configure it, now everything's open."
Roles, policies, one dialog
Roles, per-person switches, and rules down to a single field — written once, enforced the same way however the request arrives.
Run profiles
Distill best practices into virtual coworkers.
A run profile is a name, a face, a set of instructions and the tools it may use — one person's way of doing a job, saved so it can run again. Keep it to yourself or share it with the team.
Pair it with automations — a cron schedule that runs a profile's prompt on its own — and the daily standup report or morning data sweep runs itself. The longer a team uses it, the stronger its bench of virtual coworkers gets. It compounds.
One platform
Everything shares the same tool layer.
Chat
Streaming replies you can watch work, attachments of any type, a different model per message, plus branching, sharing, pinning and ⌘P search.
Knowledge base
Team, personal and shared documents — a proper editor, links between pages, version history, and search that handles Chinese.
Projects
Projects & tasks with board, gantt and tree views, members, comments, and an activity log.
Tables
Spreadsheet-like tables with real field types, views and links between records — designed by talking to the agent.
Home is a conversation
No dashboard to configure: Home is the composer, with your recent conversations under it and the team's latest changes one tap away on the bell.
Activity log + automations
Cron-scheduled assistant runs and every write your members' agents make, in one log, with every step and tool call on record.
Memory
The agent remembers what each person told it to, and notes where the tooling got in its way.
SkillHub
A shared library of agent know-how: versioned, change-logged and security-scanned, with a starter set in the box.
Email & integrations optional
IMAP/SMTP mailboxes with a server-side draft confirmation, WeCom and Feishu binding, and notifications delivered where people already are.
MCP server
Connect Claude, Cursor or anything that speaks MCP. They get the same tools, with exactly the permissions you granted.
Permissions & settings
Every feature declares what it is, so one set of rules covers every way in. Credentials and branding are edited in the browser and take effect at once.
Meta
A product for agents — built by agents.
The implementation is almost entirely agent-written; the top-level design is human-held. Every layer ships an AGENTS.md spelling out its conventions, boundaries, and domain rules — the harness for the agent that builds it. There's even an anti-entropy section: delete-and-cascade discipline, no duplicate implementations, declared capabilities must be real.
A product agents use should be a product agents can keep building. Those turn out to be the same capability.
Self-host
One command. Your infrastructure.
A single container serves the app and the API; Postgres and the database migration come with it. All you need is Docker and an API key for any OpenAI-compatible model. People sign in with an account — there is nothing to install.
# 1. configure secrets + your LLM endpoint cp .env.example .env && ./scripts/gen-secrets.sh # 2. bring it up — Postgres, migrate, API + SPA docker compose up -d --build # 3. create the first super-admin docker compose exec api pnpm admin:create → app at http://localhost:3000
Then configure it from the browser.
API keys, the product name, the logo and the colours are all edited in Administration — stored encrypted and applied immediately, right down to the login screen.
Make it yours
Your own modules, without forking the core.
An extension is two folders and one import line. It can bring its own pages, tools, tables,
permissions, search, files, scheduled jobs and commands. The core never learns your module exists, so
git merge upstream keeps working.
stays boring.
// apps/api/src/extensions/notes/index.ts export const notesExtension = defineExtension({ id: 'notes', tools: [notesQueryTool], routes: [{ path: '/api/ext/notes', app: notesRoutes }], featureFlags: [{ key: 'notes', defaultEnabled: false }], entityKinds: [{ kind: 'ext:notes:note', route: '#/notes/:id' }], searchSources: [notesSearchLane], driveScopes: [notesCabinet], migrations: { dir: extensionPath(import.meta.url, 'migrations') }, services: createNotesService, })
Switch it on per deployment in greenhouse.config.ts,
then per user with a permission toggle. A disabled extension contributes nothing at all — no tools, no routes,
no migrations.
Everywhere your team is
Light, dark, desktop, phone.
Light, dark and system themes on a responsive web app, plus a native iOS app — both against the same API.
Teams going AI-native
Use it as the foundation for an internal platform — open your tools and data top-down, hand members a day-one agent that solves real work.
Developers & builders
Read it as a worked example of how an agent platform fits together — tools, permissions, interface, MCP — then take it your own way.
Clone it. Write your first tool.
Greenhouse is an answer to what "the agent at the center of an organization" actually looks like — and an invitation.