Buildings & Agents

A building is a square placed on a project’s territory that hosts one or more agents; agents are the AI assistants that do the actual work.

Why this matters

If you’ve used a chat-style AI tool, you’ve worked with one agent at a time: open a window, type, get a reply. That breaks down the moment you want a team — one assistant that drafts PRDs, another that implements them, a third that reviews. You end up juggling tabs, copying context, and losing track of who said what.

Viberia’s container model fixes that by giving structure a physical home. A project is the scope of work. A building is the team doing one kind of work inside that scope. An agent is the individual on that team. Each layer carries its own settings, so you can configure the team once and every agent inherits — or override per agent when you need to.

The payoff: opening a building feels like walking into a room where the right people are already there, with the right tools laid out, pointed at the right folder.

The model

Three nested containers. Each one carries different responsibilities.

Layer	What it carries	User-facing surface
Project	Scope, name, on-disk folder_path, project-wide skills and MCP	Territory on the world map; HQ building for settings
Building	Team purpose, system prompt, skills, MCP servers, additional directories, UI mode	Building Window (or embedded webview for some kinds)
Agent	Role, model, optional name, optional sprite, agent-level skills/MCP overrides, memory	Agent Window with streaming chat

The project layer

The project sets the where. Its folder path is the default working directory for every agent inside it. Project-wide skills (slash commands) and MCP servers (extensions) are inherited by every building and every agent unless overridden.

You configure the project from its HQ building. Every project has exactly one HQ; you can’t delete it.

The building layer

A building is a team with a purpose. When you create a building, you pick a kind that decides which agents come with it, what tools they have, and what the building’s window looks like.

Each building carries:

• A system prompt — the team-level instructions every agent inside it sees.
• Skills — slash commands available to every agent in the building.
• MCP servers — extensions (Linear, filesystem, custom) available team-wide.
• Additional directories — extra folders the agents can read/write beyond the project’s folder_path.
• A UI mode — most buildings open as the standard Building Window showing agents and settings. A few (like the Linear building) embed an external web UI instead.

Buildings are where most of your day-to-day setup lives. You’ll spend more time tweaking a building than tweaking individual agents.

The agent layer

An agent is a specific AI assistant with a role. It inherits everything from its building and project, and can override:

• The model it runs on (Claude, Codex, Gemini, or a specific variant).
• Thinking mode and permission mode.
• Its own skills or MCP servers beyond what the building gives it.
• A custom name and sprite (the little character you see standing in the building).
• Its memory — persistent notes that survive between conversations.

You chat with an agent through its Agent Window: streaming responses, slash commands, @-mentions of other agents, mode cells showing model and permissions, tool call rendering, and conversation history.

How overrides cascade

Settings flow down. An agent uses its own value if set; otherwise it uses its building’s; otherwise the project’s; otherwise the global default from Settings → Agent Defaults.

A worked example: you set the project to use Claude as the default model. The CodeForge building inside it overrides to a faster model for the Reviewer agent specifically. Result: the Planner and Developer use the project default (Claude), the Reviewer uses the faster model. Other buildings in the project are unaffected.

Built-in building kinds

Viberia ships with a small catalog. Click a kind for its dedicated page.

Kind	Default agents	What you do here
HQ	Dean	Project settings, folder path, project-wide skills/MCP, delete project
CodeForge	Planner, Developer, Reviewer	Engineering workflow: PRD → implement → review
KnowledgeBase	Librarian	Document organization and indexing
WorktreeForge	Worktree agent	Generate and manage git worktrees
MarketResearchers	Researcher, Presenter, Analyst	Market research producing slides or analysis
Linear	Backlog Planner, Issue Writer, Issue Resolver	Linear backlog with embedded Linear UI
Generic Building	You choose	Free-form custom team

There are also three specialized buildings you can spawn from skills:

• LoopReview — Loop Orchestrator + Drafter + Reviewer, for iterative loops.
• Council — Council Orchestrator + three members, for multi-model deliberation.
• Frontend — Frontend Orchestrator + Visual + Coder, for design and code lanes in parallel.

Need something the catalog doesn’t have? Open the Building Creation Wizard — a seven-step modal that walks you through Identity, Size & Layout, Agents, Visuals, Additional Settings, UI Mode, and Review.

The main agent roles

Across all the built-in buildings, here are the roles you’ll encounter most often:

Role	Lives in	What they do
Chief of Staff	(System; CoS Overlay)	Portfolio-level coordinator. Your default conversational partner.
Dean	HQ	Per-project coordinator. Bridges CoS and building agents.
Planner	CodeForge	Turns intent into PRDs.
Developer / DeveloperA	CodeForge	Implements PRDs.
Reviewer	CodeForge	Code review and quality gate.
Librarian	KnowledgeBase	Organizes and indexes documents.
Researcher	MarketResearchers	Gathers market data.
Presenter	MarketResearchers	Builds slides from research.
Analyst	MarketResearchers, others	Trade-off and requirement analysis.
Backlog Planner	Linear	Sprint planning, /plan-sprint, /whats-next.
Issue Writer	Linear	Creates Linear issues.
Issue Resolver	Linear	Moves issues to Done.

Specialized roles (Loop Orchestrator, Drafter, Council Orchestrator, Frontend Orchestrator, Visual, Coder, etc.) show up inside specialized buildings — see Workflows.

How you interact with it

Adding a building

From the HudShelf, open the Toolbox menu or use New Building from a project’s territory context menu. Pick a built-in kind, or launch the Building Creation Wizard for a custom build. Place the building on an empty tile inside the territory.

Configuring a building

Click any building to open its Building Window. Most buildings show:

• A header with the building’s name and kind.
• Portraits of the agents inside, with status dots (idle / busy / waiting).
• A System Prompt section.
• A Skills section (enable, disable, install via /learn-skill).
• An MCP Servers section (add via /learn-mcp).
• An Additional Directories section.

The Linear building is an exception — its window embeds Linear’s web UI rather than the standard layout.

Configuring an agent

Click an agent’s portrait inside the Building Window (or click the agent directly on the map) to open its Agent Window. The window has:

• A streaming chat area with tool call rendering and message history.
• Mode cells at the top: model, thinking mode, permission mode.
• A composer with slash commands (/) and @-mentions.
• A settings drawer for per-agent skills, MCP, memory, name, and sprite.

When to set things where

You want to change…	Set it on the…
The folder this whole project works in	Project (HQ)
Which skills the whole team can use	Building
Which model one specific agent uses	Agent
A team-wide MCP server like Linear	Building
A user-wide MCP server across all projects	Settings → MCP Servers
The system prompt every agent inherits in a building	Building

Related

• World, Projects & Territories — the layer above buildings.
• Chief of Staff & Deans — how agents delegate to each other.
• Workflows — the multi-agent patterns the catalog supports.
• Building Window — the standard building UI.
• Agent Chat — the agent conversation surface.
• Building Creation Wizard — making custom buildings.