Execution Resources
What question does this solve?
Section titled “What question does this solve?”A person may be able to implement an integration and still lack the context. An agent may produce code and lack access to the right environment. An automated check may verify one condition and be unable to interpret an ambiguous rule. Deciding who or what should do a piece of work requires describing resources in terms of the work, not in the abstract.
Definition and role
Section titled “Definition and role”An Execution Resource is a person, an agent or an arrangement eligible to perform work, including decisions within delegated authority. It is defined by its relation to the work it can carry out: identity, capability and availability have to be considered against the conditions of a Delivery Stage, not as sufficient attributes on their own.
Eligibility therefore depends on conditions. The resource must be able to produce the intended output within the applicable limits of access, supervision and responsibility. Being technically available does not mean being suitable, or authorized, for any demand. The model does not require people and systems to be represented uniformly; it requires describing them well enough to route and evaluate work while preserving the differences that matter to the decision.
Why it matters for the hypothesis
Section titled “Why it matters for the hypothesis”AI can take part in preparing work as well as doing it: finding relevant references, relating decisions, producing context specific to the next transformation. When that becomes cheaper and reliable enough, it widens the situations in which capacity that is already prepared can serve parts of different projects. This is the economic link between what agents can do and organizing work in pools. Context must stay verifiable: an incorrect summary only moves effort into correction.
How it works
Section titled “How it works”Capability, availability and authorization
Section titled “Capability, availability and authorization”Capability is what the resource can do under the relevant conditions. Availability is whether it can take on the work when needed. Authorization bounds what it is allowed to do in that context. These can diverge: a qualified professional may be committed elsewhere; an available automation may have read-only permission; an authorized resource may still need preparation to understand the demand. The Execution Policy holds the rules for judging these conditions, and Routing applies them to a concrete assignment. Information about resources must be current: changes of access, configuration, availability or context can change eligibility.
What needs to be known about a resource
Section titled “What needs to be known about a resource”| Dimension | Information the decision needs |
|---|---|
| Identity | Which person, agent or arrangement will do the work? |
| Relevant capability | Which transformations can it carry out, under which known conditions? |
| Context | What knowledge is available, and what preparation is still needed? |
| Access | Which data, tools and environments may it use? |
| Availability | Which commitments and limits affect starting and continuing? |
| Supervision | Which follow-up and evaluation are required? |
| Limits of action | Which decisions and actions are outside its authority? |
| Resource use | What effort, capacity or expense might using it involve? |
The description should not suggest precision that does not exist. A forecast of availability can be uncertain, and a declared capability may need confirming in a new context. Execution history can inform capability, as long as it is related to the conditions under which it was produced: results on one kind of demand do not show equivalent performance on any other.
People
Section titled “People”A person can interpret needs, produce artifacts, evaluate outputs or make decisions within their authority, without every one of these being included in any assignment. Their work depends on knowledge, context and working conditions, and a description of competence does not replace understanding the demand or remove the effort of resuming it after an interruption. Routing several demands to someone at once does not increase their capacity to finish them. Treating a person as an Execution Resource is an operational abstraction of their participation; it does not imply unrestricted equivalence with a machine, nor does it reduce responsibility, judgment and knowledge to a single measure of capacity.
Agents and automation
Section titled “Agents and automation”An agent or an automation takes part through an execution environment, tools, inputs and defined limits. The name of a model or a tool does not, on its own, describe the capability available. A bounded automation can run a check under foreseen conditions; an agent can carry out work involving intermediate choices, and its degree of freedom should relate to the policy and to whether its outputs can be evaluated. Earlier results may stop being representative when configuration, tools, context or environment change.
Being able to start many executions does not prove a proportional capacity to deliver accepted results. Computational capacity can be prepared by configuring context, tools, environment and limits for a new execution, and starting more agents can widen part of production, but it also depends on access, infrastructure, evaluation and coordination. A process that has started is not demonstrated delivery capacity. The operation can reuse relevant configurations across demands while keeping each demand’s context separate; this is part of the hypothesis of recurring service, with the costs of maintenance and adaptation acknowledged.
Hybrid arrangements
Section titled “Hybrid arrangements”An arrangement can combine production by agents, automated verification and human analysis. Its eligibility depends on how these contributions fit together and who answers for the result of the whole. The division must make explicit what each participant receives, produces and may decide. If an agent generates an alternative and a person reviews it, the scope of that review must be recognized; human participation is not an abstract guarantee of adequacy. An arrangement can be treated as a composite resource when its internal coordination is well defined for the stage, as long as that does not hide responsibilities or dependencies. Coordinating each contribution separately can also be preferable.
Preparing and transferring context
Section titled “Preparing and transferring context”Routing work requires providing usable context: purpose, conditions in force, references to artifacts and relevant decisions. It does not mean copying all existing information to every executor, and access must match need and authorization. Some context requires interaction: an ambiguity is not resolved by sending more documents, so a resource needs a way to ask for clarification and to recognize when it cannot decide alone. Preparation has a cost: moving a small activity to a new executor can take more contextualization than continuing with the one already following the demand, without making continuity mandatory.
Substitution and continuity
Section titled “Substitution and continuity”Separating the definition of the delivery from its execution makes it possible to change resources. That does not make substitution immediate or free. Before transferring work, it is necessary to recognize what has been done, which outputs exist and which conditions remain pending, and whether the new resource continues an execution, reviews an output or starts another attempt. It must also be possible to tell whether the previous resource is still acting; a reassignment without confirmation can produce concurrent execution or incompatible outputs. Responsibility for the demand remains identifiable throughout.
In the running example
Section titled “In the running example”At the barbershop, implementation needs accepted rules and information about the existing calendar. The provider might combine a professional who knows the integration, agents configured to produce and examine changes, and tools to verify behaviours. Another configuration could assign production and evaluation to authorized systems, with functions and criteria still identifiable.
Availability has to be examined for the whole cycle. Starting several implementations does not solve a lack of capacity to evaluate or deploy them. When new requests arrive, configurations and competences can be reused where relevant, but one demand’s data and permissions do not become available to another because they share resources. The customer contracts the scope and its conditions; the provider organizes the resources and answers for the service.
Boundaries and failure modes
Section titled “Boundaries and failure modes”Direct cost is not the whole cost. Using a resource includes preparation, execution, supervision and possible rework. Comparing only the direct cost of an activity can hide relevant differences between compositions. Shared costs, such as maintaining environments and reusable context, need careful allocation. A resource is not economically suitable just because it is cheap to call.
No universal interchangeability. How to represent capacity under uncertainty and compare compositions under equivalent conditions remains open. The model makes the conditions explicit without promising that people and agents are interchangeable or offering a single ranking of resources. A description of resources that grows into an extensive classification with no effect on routing, evaluation or responsibility should be reconsidered.
Connected concepts
Section titled “Connected concepts”- Engine overview
- Next: Execution Policy, the rules that decide which resources are admissible
- Execution Pools, capacity shared across demands
- Routing, which assigns work to a concrete resource
- Glossary
Software Delivery as a Service is a proposed model by Renan Deves and Marcelo Scheidt, Independent Researchers. See the paper for citation and license.