An organization chart tells us who reports to whom. It does not fully explain how a customer request becomes a decision, how an exception finds an owner or how a business outcome gets produced.
That second view matters when people, agents and systems share the work.
At ActelosAI, a work graph is a useful analytical map for making those relationships explicit. It connects the business outcome to the tasks, context, actions, evidence and human decisions needed to deliver it.
Two maps answer two different questions
The org chart describes formal structure. The work graph describes the movement of work.
They are complementary. A work graph does not replace reporting lines, legal accountability or management responsibility. It helps reveal what happens between those boundaries: where work waits, where context is lost and where a decision has no clear owner.
Two complementary maps
Formal structure and the movement of work
Org chart
Who reports to whom?
- Formal authority
- Teams and roles
- Management responsibility
Work graph
How does an outcome get produced?
- Decisions and tasks
- Context and actions
- Evidence and exceptions
The work graph complements the org chart. It does not replace legal structure, reporting lines, management responsibility, or human accountability.
In words: the org chart answers who reports to whom through formal authority, teams, roles, and management responsibility. The work graph answers how an outcome gets produced through decisions, tasks, context, actions, evidence, and exceptions. The two maps are complementary rather than competing.
For an AI capability, this is more useful than beginning with a list of agents. The engineering question becomes: what needs to happen for this piece of work to reach a reliable, reviewable conclusion?
Start with an outcome, not an automation target
A work graph begins with one bounded business outcome. It then connects seven elements:
- Outcome: the result the work is intended to produce, for whom and within what boundary.
- Decisions: judgments that change direction, commitment, risk or acceptance.
- Tasks: the units of work that prepare, transform, check or deliver something.
- Context: records, knowledge, rules, permissions and current state.
- Actions: changes made in documents, systems, communications or the external world.
- Evidence and exceptions: what shows how the work performed and where it left the expected path.
- Learning: how those observations inform the next design or operating decision.
Anatomy of a work graph
Seven connected elements around one outcome
- 01OutcomeBounded result
- 02DecisionsDirection and commitment
- 03TasksUnits of work
- 04ContextKnowledge, policy, permission
- 05ActionsChanges made
- 06Evidence + exceptionsObserved quality and edge cases
- 07LearningWhat changes next
This is a reading path for inspection—not a required sequence, system architecture, maturity model, or claim that real work is linear.
In words: begin with a bounded outcome, then inspect the decisions, tasks, required context, resulting actions, observed evidence and exceptions, and the learning that may change the next design. The path is an inspection device rather than a required linear architecture.
This is a reading path, not a required linear workflow. Actual work can branch, loop, run in parallel or stop. The map is useful when it makes a missing relationship visible—not when it makes a complicated process look tidy.
Allocate work across people, agents and systems
“AI handles it” is not a sufficient operating design. Each important task needs an actor, an expected output, a permission boundary and a recovery path.
People set purpose and exercise judgment. Agents can prepare, search, synthesize, coordinate tools or perform bounded actions. Systems of record hold authoritative state and enforce the permissions or transactions assigned to them.
The allocation depends on the work. A deterministic service may be the best actor for a stable rule. A human may stay close to a high-consequence decision. An agent may carry out substantial work without owning the outcome.
Role allocation
Three contributors, different operating responsibilities
People
- Set intent
- Own boundaries
- Judge exceptions
- Remain accountable
Agents
- Prepare and transform
- Search and synthesize
- Use approved tools
- Execute bounded work
Systems of record
- Hold authoritative state
- Enforce permissions
- Record transactions
- Preserve evidence
These are design tendencies, not universal assignments. The appropriate actor depends on the work, consequence, evidence, permission, and recovery requirement.
In words: people may set intent, own boundaries, judge exceptions, and remain accountable; agents may prepare, transform, search, synthesize, use approved tools, and execute bounded work; systems of record may hold authoritative state, enforce permissions, record transactions, and preserve evidence. These are contextual design tendencies rather than universal assignments.
This is also a practical constraint on engineering: do not give a component more discretion simply because the technology can support it.
Choose the right configuration for each part of the work
A single workflow can combine three configurations.
Human with assistance: a person controls the work and uses AI for a bounded task.
Human-agent collaboration: people and agents divide connected work through explicit handoffs, shared context and review.
Human-led, bounded delegation: a person sets intent and boundaries; an agent carries out a longer assignment within approved permissions, stop conditions and escalation paths.
Peer configurations
Three ways to configure work
- 01Human with assistance
Person controls the sequence; AI supports a bounded task.
- 02Human-agent collaboration
People and agents divide connected work through explicit handoffs.
- 03Human-led, bounded delegation
A person sets intent and boundaries; an agent executes within permission and stop conditions.
These are peer configurations—not stages, maturity levels, a required journey, or evidence that more delegation is better.
In words: human with assistance, human-agent collaboration, and human-led bounded delegation are three peer configurations. They can coexist within one workflow and do not form a maturity ladder.
These are choices, not stages of maturity. More delegation is not inherently better. An organization can use a highly automated preparation process while keeping the consequential decision directly human-owned.
Separate execution from decision rights
Autonomy is not one permission. A capability can be allowed to prepare a recommendation without being allowed to approve it, commit funds or change a system of record.
The six rights below make that distinction easier to examine: initiate, access, act, approve, override and accept.
Decision-rights map
Six rights to assign explicitly
- 01InitiateWho may start the work?
- 02AccessWhich context and systems?
- 03ActWhich changes may be made?
- 04ApproveWho authorizes consequential output?
- 05OverrideWho can interrupt or redirect?
- 06AcceptWho owns the result?
Keep consequential decisions, operating boundaries, approvals, and accountability with identifiable human owners.
The assignment is contextual. This framework does not require people to perform every step, and it does not define legal, contractual, or liability allocation.
In words: assign who may initiate work, what may be accessed, which actions may be taken, who approves consequential output, who can override the path, and who accepts the result. Keep consequential authority and accountability with identifiable human owners.
In ActelosAI’s delivery model, the client assigns the relevant authorities. ActelosAI can design and implement agreed controls, but technical access does not itself grant business authority.
The same applies to a scope change. Permission to operate within one workflow does not include permission to reach a new dataset, make a new type of commitment or expand into another department.
Design for exceptions and learning
The happy path is only part of an operating model. What should happen when a source is missing, two records disagree, a tool fails or an action exceeds permission?
An exception needs somewhere to go. Name who reviews it, what evidence they receive and what allows the work to continue, remain bounded or stop.
Learning also needs an owner. Observations may lead to a change in context, workflow, permissions, tools or evaluation. They should not silently increase an agent’s authority.
Bounded learning loop
Evidence returns to a human operating decision
- 01Run bounded work
- 02Capture evidence
- 03Surface exceptions
- 04Human operating decisionChange, hold, narrow, or stop
- 05Update the designWorkflow, context, permission, tools, agent, or evaluation
If the human owner chooses to continue, the updated design returns to another bounded run.
This is one possible learning loop—not proof of continuous improvement, automatic scaling, or a requirement to increase delegation.
In words: run bounded work, capture evidence, surface exceptions, make a human operating decision to change, hold, narrow, or stop, and update the design only when chosen. A continued workflow then returns to another bounded run.
The loop ends in a human operating decision before another bounded run. Capturing feedback is not the same as improving the capability; the proposed change still needs review.
Turn the work graph into a capability design
The work graph is an analytical aid, not an extra layer of Actelos Delta or a software platform clients must adopt.
Its practical contribution is to make the selected workflow concrete enough for capability design. Within Delta, that means translating business reality into the smallest operable capability and the evidence needed to evaluate it.
Forge addresses the engineering: implementing the application or workflow, connecting authorized data and tools, setting review points, testing failure paths and preparing the operating assets for handover.
A useful design can answer:
- Which outcome and users does the capability serve?
- What context and permissions does each important task need?
- Where may software act, and where must a person decide?
- What happens when the expected path fails?
- What evidence supports acceptance, and who owns ongoing operation?
Those answers may lead to a workflow, an integration, a decision tool or a bounded agent. The graph does not predetermine the form.
Begin with one piece of work
Choose one important workflow and trace it with the people closest to it. Include an ordinary instance and a meaningful exception. Compare what the documented process says with what people actually do.
Make the next decision explicit: clarify a handoff, change a rule, improve a data connection, test a bounded AI capability—or leave a part of the work unchanged.
If the result supports a larger scope, re-examine the map in that new context. Delta’s evidence-gated expansion is not permission to copy a working design unchanged.
Actelos Delta provides the method for choosing and proving that change. Actelos Forge provides the engineering and delivery path. For the responsibilities connecting them, read What Is a Forward Deployed Engineer?.
The goal is not to redraw the organization. It is to make the work, its ownership and its next decision clear enough to operate.