Agents
Agents are participants, not plugins.
An agent in CORE has an identity, an owner, scoped permissions and an audit trail. It invokes capabilities like any other participant, and it does not get unrestricted database access.
Participants
First-class, with an owner
Every agent has its own identity in the Identity layer and an owner set through agent.owner.set: the human or organization accountable for what it does. Permissions are granted to the agent, not borrowed from a user, so they can be narrower than any person’s.
Because agents are participants, the rest of CORE needs no special case for them. The same relationships, the same permission formula and the same events apply.
Identity
An agent authenticates as itself, with an owner who is accountable.
Permissions
Granted to the agent directly, so they can be narrower than any person’s.
Audit
Every action is an event with the agent as actor and the approver when there is one.
Autonomy
The autonomy ladder
Autonomy is a setting, not a property of the agent. The same agent can observe one capability, suggest another and execute a third within policy. Each rung names who invokes the capability and when a human decides.
- 01No approval needed
Observe
The agent reads what its permissions allow and reports. Nothing changes.
ExampleA weekly summary of open orders.
- 02Human invokes
Suggest
The agent proposes an action; a human decides whether to invoke it.
ExampleSuggests a headline; you edit and publish.
- 03Human invokes
Assist
The agent prepares the action and its preview; a human invokes it.
ExampleDrafts the invoice for a customer; you send it.
- 04Approval before execution
Execute with approval
The agent invokes the capability; CORE holds it until an authorized human approves.
ExamplePublishes the product after your approval.
- 05Within policy
Execute within policy
The agent invokes directly within limits set by policy; every action is audited and reversible where the capability allows.
ExampleRolls back a failed deployment at night.
Mechanics
How an agent acts
Intent, identity, permission, capability, event. The agent forms an intent and resolves it to a capability. CORE resolves the agent’s identity, checks the permission, runs the capability and records the event with the agent as actor and the approving human when there is one.
- Intent: site.content.update (The agent resolves its goal to a named capability.)
- Identity: website-agent (Its own identity, with an owner who is accountable.)
- Permission: can(site.content.update) · allowed (Granted to the agent, not borrowed from a person.)
- Capability: typed input · one transaction (Nothing outside the capability is reachable.)
- Event / Audit: site.content.updated (Actor: the agent. The approver is recorded when there is one.)
Map
Where agents sit
Agents are one of the participants on the orbit around CORE. Select a node to see the layers it reads and the capabilities it may invoke.
Interface
Agents
Actors with their own identity, an owner and scoped permissions; every action leaves an audit event.
Uses
- Identity (used)
- Organizations
- People
- Relationships
- Knowledge (used)
- Workflows (used)
- Commerce
- Finance
- Communication (used)
- Data
Example capabilities
site.publishdeployment.rollbackworkflow.start
Agents selected. Uses 4 of 10 layers.
- CORE
- The shared operating layer. Ten layers: Identity, Organizations, People, Relationships, Knowledge, Workflows, Commerce, Finance, Communication, Data.
- Website (interface)
- Public sites and portals that read content and catalog data and submit forms through CORE. Uses the Identity, Knowledge, Commerce and Data layers. Example capabilities: page.get, catalog.list, form.submit.
- Applications (interface)
- Internal, mobile and dashboard apps: views into CORE with the signed-in identity's permissions. Uses the Identity, Organizations, People, Workflows and Data layers. Example capabilities: customer.get, workflow.start, approval.decide.
- Chat (interface)
- 2finity.chat and other conversational interfaces: language resolved to capabilities, with approval. Uses the Identity, Knowledge, Workflows, Finance and Communication layers. Example capabilities: site.content.update, invoice.create, permission.grant.
- Agents (interface)
- Actors with their own identity, an owner and scoped permissions; every action leaves an audit event. Uses the Identity, Knowledge, Workflows and Communication layers. Example capabilities: site.publish, deployment.rollback, workflow.start.
- People (participant)
- Humans in any context: professional, employee, customer or supplier, with one identity throughout. Uses the Identity, People, Relationships and Communication layers. Example capabilities: customer.get, permission.grant, message.send.
- Companies (participant)
- Organizations that own their data, run their workflows and decide who and what may act inside them. Uses the Organizations, People, Relationships, Commerce and Finance layers. Example capabilities: organization.get, invoice.create, order.update.
- Partners (participant)
- Other organizations connected by a relationship: suppliers, resellers and agencies see what it grants. Uses the Identity, Relationships, Commerce and Data layers. Example capabilities: catalog.product.get, order.update, permission.grant.
- Enterprise (participant)
- Large organizations running CORE in an isolated deployment with their own identity provider and policies. Uses the Identity, Organizations, Workflows, Finance and Data layers. Example capabilities: permission.grant, deployment.publish, workflow.start.
Boundary
No database access
Agents invoke capabilities. They do not get unrestricted database access. A capability has a known input, a known permission and a known event; a database connection has none of these.
The boundary is what makes autonomy affordable: scope is explicit, every action is audited, and anything a capability can do can be reversed through another capability.
Control
Approval and policy
Privileged capabilities such as site.publish, permission.grant and invoice.send require a human decision through approval.decide before they run. Policy can delegate a bounded set to the agent, for example rolling back a failed deployment, and every delegated action still emits an event.
The owner can tighten or widen the policy at any time; the change is itself a recorded capability.
Status
Where this stands
The contract that agents use exists on this site: identity, permissions, capabilities and events are modeled and tested. An agent runtime with policies and tooling is the planned scope of 2finity.ai.