A process can be divided into tasks while authority over its decisions remains unclear. When agents can call tools, that ambiguity may become an access grant, deletion or consequential external communication. Work architecture must therefore specify more than the sequence of steps.
I propose Agentic Process Architect as a name for the function connecting business needs, delegation, controls and expected evidence. A mandated person or team can hold this responsibility. The name implies neither a regulated profession nor an absence of equivalent expertise in existing organisations.
Approved onboarding changes its meaning
Consider a new employee. A manager approves read-only access to a document space. One agent prepares the request and another maps it to the entitlement catalogue. An incorrect correspondence turns the read-only profile into an administrator role. The record still says “approval obtained”.
If the provisioning service checks only that status, it may grant permissions that nobody approved. The employee could alter documents, delete material or expand access. Severity depends on the resources; correct account authentication does not make those permissions appropriate.
An ambiguous role name, changed catalogue or summary that loses approved parameters could produce this failure. Diagnosing it does not require attributing malicious intent to the model.
Approval concerns a defined operation. The word “approved” does not grant general permission to its subsequent transformations.
Assign responsibilities before execution
Design starts with what the business intends to authorise: resource, operations, duration and special conditions. The business owner qualifies the need. The resource owner defines available entitlements. Security examines conflicting rights and privileges. The designated authority approves within its mandate. The execution component rechecks the request it will actually apply.
Organisations may allocate these duties differently, but the responsibilities must remain identifiable. An agent matching role names does not thereby gain permission to choose an entitlement exception.
A reusable method should specify required inputs, accepted mappings and ambiguity handling. If a role differs from the approved profile, preparation can continue while the sensitive grant waits for the appropriate decision. OWASP’s high-impact action guidance recommends binding approval to the exact action and separating proposal from execution.
Exceptions remain explicit decisions
If the role genuinely needs to change, the process should present the new permissions and their justification to the authorised decision-maker. The old approval cannot be reused as if its parameters were unchanged. A technical comparison can expose a difference; it does not decide whether the new need is legitimate.
Recovery requires similar care. Revoking access after provisioning does not recall copied data or undo changes made while it was valid. Handling the discrepancy requires understanding effects, limiting further operations and assessing possible recovery measures. Reversibility must be assessed rather than assumed.
How this translates into Swarm
Swarm organises plans, tasks, dependencies and validations. Its contracts distinguish producing a result, control evidence and the decision to proceed. In the Rust Trust pilot, action requests, mandates, parameters and approvals are distinct objects. A local access connector produces simulated effects; it does not connect to an enterprise directory.
These mechanisms support process architecture. They do not determine the correct entitlement instead of the business owner. A local identity or approver role does not, by itself, establish a human decision-maker’s identity. Resource integration, alternative paths and general confinement require qualification for an actual deployment.
What must be explainable afterwards
For onboarding, an investigation needs the requested profile, approved parameters, catalogue version, decision authority and actually granted permissions. It also needs to identify who can suspend the next step and who owns the exception.
This responsibility remains useful when models or tools change. It makes delegation boundaries and success criteria explicit instead of leaving orchestration to decide them implicitly. The Swarm repository exposes the contracts I develop to support this approach.