Concepts · 01
The AI-managed company
Ergon is not a chatbot framework. It is the operating layer for a kind of organization that did not exist five years ago: one where self-governing AI systems plan and execute work, alongside humans, on a shared model of the business — under rules the humans set.
The thesis
The long-term shape of an organization is not “software with AI features”. It is a place where artificial intelligence is one of the things that operates the company — not a feature bolted onto an existing app, not a copilot in the corner, not a single super-prompt running in someone's notebook.
Humans do not disappear. They set intent, approve structural change, handle exceptions, and partner with AI on strategy. But the heavy lifting — routing work, updating state, talking to customers, keeping processes honest, reacting to events — moves onto systems that can run continuously, consistently, and at scale.
For that to work safely, those systems need an operating layer. They need identity, permissions, structured processes, communication channels, documents, data, memory, and audit — all sharing the same governance with humans. They need to be able to interact with the same modeled world without stepping on each other or bypassing oversight.
Ergon is that operating layer.
What actually changes
The shift is not “add an LLM endpoint”. It is structural. Five things move at once when an organization adopts the AI-managed model:
Identity
Agents become first-class participants, not API consumers.
An agent has its own principal — the same kind of identity a person or an integration has. It owns grants. It owns conversations. It owns semantic memories. It is on the org chart. The policy engine asks the same question for an agent that it asks for a human: is this principal allowed this action on this resource?
Process
Work lives in a shared model, not in one team's tool.
Workflows model how work moves; worksheets model facts; buckets models artifacts; conversations model dialogue; channels model the outside world. Humans and agents read and write the same model through the same gates.
Reaction
“Something happened” is first-class.
Every state change in every service emits an event. Automations subscribe to those events and dispatch step graphs that can invoke agents, send messages, transition items, schedule waits, and write back. Reaction is a substrate, not a feature one team builds for itself.
Memory
Agents remember what they learn, with the user's consent and in plain sight.
Continuity over weeks and months — not just within a chat turn. Memory is shared by default so an agent feels like a real teammate, but every conversation has a one-toggle privacy switch and every recall is disclosed in the conversation itself. Hidden memory is a design failure; we do not provide the code path for it.
Autonomy
Copilot to operator is a permissions decision, not a rewrite.
The same agent runs as a suggestion engine, then a co-worker, then an autonomous operator — by widening or narrowing grants. There is no separate “autonomous mode” product. Autonomy is policy.
The six problems we solve
Anyone trying to build an organization where AI plans and executes work will run into the same six problems. We share our answers freely; the implementation is our craft.
How do you let an agent act without becoming a superuser?
Treat agents as ordinary IAM principals. Every action an agent takes is checked by the same engine that checks a human action — same actions, same resources, same allow and deny rules. There is no privileged AI bypass. The difference between a careful agent and a reckless one is the grants in its principal, not the code path. Read the identities concept →
How do agents talk to each other safely?
Through Conversations — the same substrate humans use. Agent A invites agent B into a conversation. B's tool calls execute under B's grants, never A's. Audit, history, message replay, and human observation all come for free, because the substrate is uniform. We did not build an agent-to-agent protocol; we made every conversation accept any principal. Read the multi-agent concept →
How does an agent remember without surveilling?
Memory is derived from conversations the user has marked shareable; it lives in the same governed Buckets service as everything else; every recall is announced in the conversation; every memory entry is browsable in the UI; every conversation can be made private with one click. Memory is not a hidden side-channel — it is part of the contract between the agent and the user. Read the memory concept →
How do agents react to things happening in the company?
Every state change in every service emits a typed event (ticket created, document uploaded, message received, row updated). Automations subscribe to those events and dispatch step graphs that can invoke agents, send messages, transition items, schedule waits. The agent does not poll. The agent does not have to know about the rest of the company. The platform routes the reaction. Read the autonomy concept →
How do you distribute work across humans and agents?
Workflows are the shared model of how work moves — phases, fields, transitions, automations. Humans and agents operate on the same items and the same transitions. A routing decision (“send the next ticket to whoever is available”) consults the IAM policy layer for working hours, IP allowlists, and availability status, then assigns to a human or to an agent depending on what is allowed. Distribution is a property of the shared model, not a separate feature per channel. Read the workflows guide →
How do you go from copilot to autonomous operator?
By widening grants. An agent that started read-only can be trusted with edits. A conversation that needed human approval becomes auto-approved for low-risk inputs. A workflow phase that required manual transition becomes auto-transitioned by an automation. Same agent, same code, different mandate. The gap between “assistant” and “operator” is largely permission and process design, not a rewrite of the platform.
The shape of the platform
Ergon is composed of services that together form the substrate of an AI-managed organization. Each one is a small answer to a large question.
IAM
Who is allowed to do what?
Single principal model, zero-trust federated zones, working hours, IP policy, statuses, and permission evaluation for every actor.
Workflows
How does work move?
Phases, fields, transitions, automations. The shared model of operations.
Conversations
Where does dialogue happen?
The substrate for human↔human, human↔agent, channel↔agent, and agent↔agent. Every participant is an IAM principal.
Agent Hub
Who is the agent, and what can it do?
Configuration, prompts, models, tools, memory. Each agent owns its own identity and behavior.
Channels
How does the company talk to the outside?
Governed surfaces to email and beyond. Every send and receive is tied to identity and audit.
Worksheets
What facts are true right now?
Structured data with typed columns, views, and formulas. The fact base humans and agents share.
Buckets
What evidence and artifacts back the work?
Folders, documents, ingestion pipelines, semantic search. Memory lives here. Attachments live here.
Automations
When something happens, what should happen next?
The reaction substrate. Subscribes to events from every service and dispatches step graphs.
Event Streams
What did we record when it happened?
The central audit ingestion. Every domain event from every service flows here for query and replay.
What we share — and what we don't
We give the knowledge of how to solve these problems away. Every concept page in this section is meant to be useful to a team that decides to build something similar themselves. We'd rather raise the floor of what “responsible agentic AI” means than win on having the only recipe.
What we do not publish is the implementation: the policy engine, the runtime, the worker topology, the per-service schemas, the orchestration code. Those are the work. They are also why a company adopts Ergon instead of writing it.
A note for engineers reading this
If you are evaluating this platform: the API reference under each service is the source of truth for what you can call today. The concepts in this section are the reasoning behind why the API looks the way it does. Both halves are public and stay in sync.
How to read these docs
Three layers, in order:
- Concepts — the section you are reading now. The worldview. Read top to bottom if you want the philosophy. Skim if you just want to know which words mean what.
- Guides — how each service feels in practice, with examples. Best when you have a concrete thing to build and want to know which endpoints to chain.
- API Reference — every endpoint, every field, every response code, every event type. Source-of-truth for integration work.
If you are new and have ten minutes, read Identities & Boundaries next. It is the single most important concept in this platform; everything else assumes it.
Coming from a traditional SaaS mental model?
The single biggest adjustment is this: agents are users, not background jobs. They have IDs. They sit in conversations. They get added to teams. They hold grants. They appear in audit logs. Every other concept on this site falls out of that one decision.