Skip to content
scsiwyg
sign insign up
get startedmcpcommunityapiplaygroundswaggersign insign up
Worksona·Worksona Teams: The Agent Content Layer That Powers the Portfolio17 Apr 2026David Olsson
Worksona

Worksona Teams: The Agent Content Layer That Powers the Portfolio

#worksona#portfolio#agents#knowledge-management#filesystem#organizational-design

David OlssonDavid Olsson

Infrastructure without content is scaffolding. Worksona Teams is the content — a structured repository of 100+ organizational role agents that every Worksona platform project draws from, with no application code of its own.

What It Is

Worksona Teams is a filesystem-based agent registry. It is not a running service, a library, or an API. It is a directory of directories, organized into 19 functional categories, where each agent definition lives as two files: a metadata.json carrying the agent's name, category, capabilities, and model recommendation, and an agent.md containing the full system prompt.

The 19 categories span the complete organizational function spectrum: board of directors and investor panel at the governance level; C-suite executives and business strategy at the leadership level; software engineering, software architecture, distributed systems, cloud infrastructure, DevOps, data engineering, AI/ML, security operations, and performance reliability across technical functions; and consultancy agents, customer engagement, content documentation, elite research, and programming language specialists rounding out the collection.

No platform dependency is required to add an agent. No platform dependency is required to read one. The format is chosen so that any tool capable of reading a directory can work with it.

Why It Matters

Three design decisions make Worksona Teams more than a folder of prompt files.

Filesystem-as-registry. The directory structure is the registry. Discovery happens via glob('**/metadata.json') — the same mechanism a developer would use to list files in a shell. Creating an agent is a git commit. Reviewing a new agent definition is a pull request. Deleting an outdated agent is a file deletion. No admin interface, no schema migration, no deployment required.

Content and infrastructure are fully separated. Worksona Teams owns agent definitions and nothing else. The platforms that consume it — worksona-mcp-server, agent-mcp, worksona-api — own their own runtimes. Each can evolve independently. A change to the MCP server's coordination logic does not touch agent content. A new agent added to Teams is immediately available to every consumer that mounts the directory.

Organizational completeness as a design goal. The scope of coverage is deliberate: the repository is designed to be immediately useful to any organization without requiring customization. Having a board-level governance agent alongside an IC-level programmer agent makes the library useful across organizational levels and cross-functional scenarios from the start.

How It Works

Each consumer mounts the repository differently. worksona-mcp-server receives the path via a WORKSONA_TEAMS_PATH environment variable and globbs it at startup, building an in-memory index of available agents. worksona-api references the same organizational model to configure its 24 built-in agents. Extended projects like a-teams layer team formation logic on top of the same base definitions.

Because every agent definition is a plain text file in git, the audit trail is built in. Every change to a system prompt, every new agent added, every capability description updated — all of it is visible in the repository history. Domain experts can author and review agents using tools they already know.

Where It Fits in Worksona

Worksona Teams occupies the shared content layer position across the entire portfolio. It is the single source of truth that every agent platform project depends on, which makes it the most broadly consumed asset in the ecosystem.

This positioning reflects a portfolio-level architectural decision: separate what agents know and how they behave from the infrastructure that executes them. The filesystem-as-registry pattern defined here propagates to every MCP server and API project that consumes it.

The result is a system where updating an agent's expertise requires a text editor and a git commit, and that change is live across every connected platform the next time they load their agent index.

Share
𝕏 Post