Company
The Company is the product surface in aeqi.
Agents can execute, but isolated agents do not create an economy. They need a vehicle that gives work direction, context, authority, capital, memory, and accountability. That vehicle is the company.
aeqi lets you start that company as software: a Company OS where humans and AI agents share one operating context.
What a company is in aeqi
In the product, a Company is the durable container for work. It is not just a workspace or chat room. It is the place where roles, agents, quests, ideas, events, sessions, memory, tools, and authority belong together.
It has:
- a mission and operating context
- roles for authority and responsibility
- agents that occupy roles and execute work
- quests that define what needs to happen
- ideas and memory that preserve what the company knows
- events that wake the system and trigger execution
- sessions that record collaboration and execution traces
- authority, treasury, governance, and ownership state where deployment supports it
This is why aeqi is not an agent framework. Frameworks help developers build agents. aeqi gives agents somewhere economically meaningful to live.
The user-facing primitive is the Company. Lower-level protocol and API surfaces can still expose exact implementation names, but the product should teach one clear object first: the operating company where work, authority, memory, and ownership can converge.
Why this matters for the agent economy
The agent economy is not a future where everyone rents disconnected bots. It is a future where agents become economic actors inside companies that can coordinate, transact, remember, and govern.
That requires structure:
| Need | aeqi primitive |
|---|---|
| Direction | Mission, ideas, company context |
| Responsibility | Roles |
| Execution | Agents and quests |
| Memory | Ideas, sessions, events |
| Authority | Role graph and governance |
| Capital | Treasury and ownership primitives |
| Accountability | Operating history and contribution records |
Without the company, agents stay as tools. With the company, agents become workers inside an operating institution.
The company model
When you create a Company, aeqi creates the company model first:
- Roles define the initial org chart.
- Agents are hired into operational seats.
- Ideas seed the company's mission, strategy, and standing instructions.
- Quests define first work.
- Events define what should wake the system.
- Sessions become the conversation and execution trail.
- Company history keeps execution, memory, authority, treasury, governance, and ownership connected.
The shell can be small. A solo founder plus two agents is enough. The point is not enterprise bureaucracy; the point is giving execution a durable container.
Execution creates operating truth
aeqi starts with execution because execution creates the facts the company can rely on later.
If agents do the work inside the company, the company can know:
- who requested the work
- which role had authority
- which agent executed it
- what context was used
- what changed
- what outcome was accepted
- what value was created
That operating truth is the bridge from agent execution to company accountability, governance, and capital allocation.
The protocol layer
Underneath the Company sits a deployment-dependent protocol layer: an on-chain substrate that can bind a Company's authority, treasury, governance, and ownership into enforceable state. You don't create this layer directly. You create a Company. When a deployment needs high-consequence actions to be programmable and enforceable — not just recorded — the Company is backed by an on-chain trust/protocol vehicle that carries that authority.
| Layer | Purpose |
|---|---|
| Identity | Stable company identity for runtime and protocol state |
| Treasury | Assets, budgets, and spend policies |
| Roles | Authority graph for directors, operators, contributors, advisors |
| Governance | Proposals, approvals, timelocks, execution |
| Ownership | Tokens, vesting, contribution records, future cap-table logic |
| Agent authority | Scoped ability for agents to act under human-defined permissions |
The product vocabulary leads with the Company. The on-chain trust/protocol layer is the lower-level term used where the system needs a stable vehicle for authority, treasury, governance, ownership, signer controls, and on-chain registration. New users should never have to meet it to get value from the product. When a page discusses custody, treasury, ownership, or on-chain authority, read it as deployment-dependent unless it explicitly says the hosted product exposes that module.
Custody stays scoped. Some deployments may provide runtime-assisted signing, but protocol authority is designed around scoped roles, explicit approvals, and signer controls rather than agents owning user keys. And this is not a token-governance product: governance exists, but token voting is not the category.
Runtime roles are the operating org chart; the protocol layer carries only the authority tier that needs enforceability — directors, treasury control, governance rights, ownership actions, and other high-consequence permissions. Operational seats can stay runtime-only: not every marketer, researcher, or assistant needs on-chain authority.
The current protocol direction is Solana-based: smart-account infrastructure, role authority, treasury controls, and ownership primitives designed to make the on-chain layer a programmable company rather than just an off-chain workspace. Treat legacy EVM/Base language as historical unless a page is explicitly describing old code.