Regulated Agentic Architecture — Foundations and Structure

1. The problem

Large language models — commonly known as LLMs — can interpret new situations, devise strategies, and adapt responses to context. This flexibility is what makes them useful. It also creates a problem: in consequential operations, receiving a plausible response is not enough. It must be possible to know which task was assigned, what information could be used, which limits had to be respected, and what constitutes a valid deliverable.

The Regulated Agentic Architecture — AAR organizes this kind of operation.

Its purpose is not to program every step of an LLM's reasoning. It is to clearly define:

what must be done;
what information the LLM may operate on;
which limits must be observed;
what outcome must be delivered;
how to determine whether the operation has ended;
what may happen next.

AAR structures capabilities executed by LLMs as operations with bounded responsibility, defined authority, verifiable outcomes, and governable continuity.

2. The central idea

The fundamental unit of AAR is the Unit of Contractual Capability — UCC.

A UCC describes a bounded task for an LLM. It states the objective, permitted inputs, applicable controls, expected operations, required outcome, and possible paths of continuity.

An ordinary instruction might say:

Analyze these documents.

A UCC must make the responsibility more precise:

Contract questions
├─ What is the objective?
├─ What information may be used?
├─ Which limits must be respected?
├─ What must be produced?
└─ How can a valid conclusion be recognized?

The LLM remains free to interpret and solve the problem. The architecture defines the authority and obligations of that execution.

3. Fundamental structure

AAR has three contractual elements and one executor:

Fundamental structure
├─ 1. Compose: Kernel + Profile + UCC
├─ 2. Form: active contract
├─ 3. Execute: LLM
└─ 4. Produce: outcome and continuity

In direct terms:

Kernel: brings together the rules common to the entire architecture;
Profile: brings together policies shared by a capability or domain;
UCC: defines a specific operation;
LLM: interprets the contract and executes the operation.

AAR was conceived for capabilities executed by LLMs. The LLM may use authorized sources and tools, but remains the executor responsible for the contracted operation.

3.1 Kernel

The Kernel establishes the rules that should not change with every new capability. It provides a common vocabulary for responsibility, authority, execution, outcome, and continuity.

Kernel rules may address:

priority among instructions;
treatment of inputs;
validity of outcomes;
states and transitions;
publication and continuity;
compatibility among components.

The Kernel does not contain the substantive knowledge of each domain. It defines how a regulated capability works.

3.2 Profile

The Profile brings together rules shared by a set of related operations. It sits between the general Kernel and each specific UCC.

The Profile may define:

the identity of the broader capability;
authorized sources and resources;
common policies;
shared limits;
domain conventions and rules.

Its function is to prevent the same policy from having to be repeated in every UCC.

3.3 UCC

The UCC defines a specific responsibility. It is not merely a question or instruction: it is the structured description of an operation and its validity conditions.

In simple terms:

The Kernel defines the general rules. The Profile defines the shared policy. The UCC defines the work. The LLM executes it.

These layers follow an order. A more specific layer may detail or restrict the preceding one, but it cannot eliminate its fundamental rules.

Order of specialization
├─ 1. Kernel — general rules
├─ 2. Profile — specializes the Kernel
├─ 3. UCC — specializes the Profile
└─ 4. LLM — executes the contract

4. Anatomy of a UCC

Every UCC must answer six questions:

UCC — Unit of Contractual Capability
├─ Identity — what is the operation and what is its objective?
├─ Scope — what information and resources may be used?
├─ Regulation — which rules and limits must be observed?
├─ Execution — what must be done?
├─ Outcome — what must exist at the end?
└─ Continuity — what happens next?

Identity makes the unit recognizable. It defines its name, objective, and assigned responsibility.

Scope delimits the inputs, sources, prior outcomes, guidance, and tools that may be used. Information available in the environment is not automatically authorized.

Regulation brings together controls, prohibitions, criteria, and conditions for completion or blockage. It prevents cognitive freedom from becoming unrestricted authority.

Execution describes the necessary operations and transformations. It must be clear enough to delimit the work without turning the LLM's reasoning into a rigid sequence of micro-instructions.

Outcome defines the mandatory content, completeness criteria, necessary evidence, and form of presentation.

Continuity states whether the operation has ended, must wait, is blocked, needs to return to an earlier stage, or allows another UCC to begin.

4.1 Modular representation of a UCC

A UCC may be represented concretely as a module. The module organizes the operation's contract and makes visible the relationship among rules, inputs, actions, deliverables, and continuity.

Kernel
└─ family profile
   └─ module
      ├─ module controls
      ├─ inputs and views from the active route
      ├─ delivery cores, in order
      │  ├─ local objective
      │  ├─ substantive actions
      │  ├─ local controls
      │  └─ deliverables, in order
      │     ├─ content contract
      │     └─ rendering
      └─ closure and next step

In this structure:

family is a set of operations that share a purpose and Profile;
active route is the execution path applicable to the current situation;
views are outcomes published by previous operations and authorized as inputs;
delivery core brings together the objective, actions, controls, and deliverables of a coherent part of the work;
closure records the operation's outcome and the permitted continuity.

The module is not a different unit from the UCC. It is the structured form through which a UCC may be declared and executed.

5. Architectural principles

5.1 Freedom of reasoning

The LLM may interpret the problem, choose a strategy, explore relevant aspects in depth, and formulate the outcome. The UCC regulates the operation, not the internal chain of reasoning.

5.2 Bounded responsibility

Each UCC has its own responsibility. It must not silently take on the work of another unit merely because the LLM would be capable of performing it.

5.3 Explicit authority

Being capable of doing something does not mean being authorized to do it.

LLM capability is not equivalent to operational authority

Authority derives from the applicable Kernel, Profile, and UCC.

5.4 Contracted outcome

A response ends the operation only when it satisfies the required outcome.

a produced response is not equivalent to a completed operation

5.5 Explicit continuity

Closure must indicate a state that the architecture can understand. Continuity cannot depend solely on an informal interpretation of the produced text.

6. Boundary between autonomy and contract

Within the contract, the LLM may:

interpret the problem;
choose a compatible strategy;
explore relevant aspects in depth;
reconcile authorized information;
formulate conclusions and adapt the language;
use permitted tools.

The LLM may not:

redefine the UCC's responsibility;
expand the authorized scope;
ignore an applicable control;
consider a pending obligation fulfilled;
create an unforeseen state;
improperly assume the responsibility of another UCC.

The synthesis of this boundary is:

Cognitive freedom within contractual authority.

7. Execution cycle

An execution moves through recognizable functions:

Execution cycle
├─ 1. Load the contract
├─ 2. Identify the active UCC
├─ 3. Resolve the authorized scope
├─ 4. Check controls
├─ 5. Execute the operation
├─ 6. Form the outcome
├─ 7. Validate the outcome
└─ 8. Publish and define continuity

If a necessary condition is not met, the architecture must produce a corresponding state, such as waiting, blockage, or return. It must not present an incomplete operation as completed.

This cycle describes minimum functions. It does not require the LLM to follow a single internal order of reasoning.

7.1 AAR as an abstract execution machine

The cycle makes it possible to formulate AAR as an abstract execution machine. The expression does not designate a specific device or program. It indicates that the architecture defines inputs, control functions, outcomes, and state changes without determining the LLM's internal reasoning.

Abstract execution machine
├─ 1. Receive: contract + current state
├─ 2. Prepare: operation
├─ 3. Execute: cognition by the LLM
├─ 4. Form: candidate outcome
├─ 5. Validate: contract
└─ 6. Produce: published outcome + new state

In the algorithmic unfolding of the architecture, cognitive execution sits between two control layers:

UCC execution
├─ 1. Apply: prior algorithmic control
├─ 2. Execute: free operation by the LLM
└─ 3. Apply: subsequent algorithmic control

The prior control prepares the contract, resolves the scope, and checks the initial conditions. The subsequent control checks the outcome, determines its validity, and defines continuity. The LLM remains the executor of the capability.

AAR is a contractual state machine whose cognitive operator is an LLM.

7.2 Three algorithmic functions

Complete execution can be decomposed into three functions:

Compose the contract: combine Kernel, Profile, and UCC according to their order of authority.
Execute the UCC: provide the contract and scope to the LLM and validate the produced outcome.
Resolve continuity: transform the outcome and current state into publication, return, waiting, blockage, or termination.

Complete execution
├─ 1. Compose: Kernel + Profile + UCC
├─ 2. Form: active contract
├─ 3. Execute: LLM
├─ 4. Produce: candidate outcome
└─ 5. Resolve: validation and continuity

Some checks can be objective: presence of inputs, compatibility, authorized sources, mandatory components, permitted states, and form of publication. Substantive correctness, sufficiency of evidence, and quality of analysis require domain criteria and may depend on additional evaluation by an LLM or human decision.

The Appendix presents the complete conceptual algorithm.

8. Composition of capabilities

A UCC may represent a complete operation or be part of a broader capability. When several UCCs are combined, each preserves its responsibility.

Profile composition
├─ UCC 1
│  └─ produces: Outcome 1
├─ UCC 2
│  └─ produces: Outcome 2
└─ UCC 3
   └─ produces: Outcome 3

Continuity rule
└─ each outcome authorizes another UCC or termination

The outcome of one UCC may become an authorized input to another. This passage must be defined by the architecture; it must not depend on presumed context.

Composition makes it possible to divide a complex capability into smaller responsibilities without attempting to divide the internal reasoning of each operation.

As the system grows, additional questions arise:

which outcome is currently in force;
which UCC may consume it;
when the next operation may begin;
what to do in the event of blockage or an invalid outcome;
when a previous operation must be performed again.

New architectural mechanisms should arise to meet needs such as these, not merely to increase the level of formalization.

9. Architecture and domain

The architecture defines the form of the capability. The domain supplies its content.

The architecture:

delimits responsibilities;
distributes authority;
organizes execution and continuity;
defines how outcomes are validated.

The domain:

defines which operations are necessary;
supplies knowledge and sources;
establishes substantive criteria;
determines which outcomes are useful.

AAR
└─ shared structure
   ├─ Domain A
   │  └─ Profile A
   │     └─ UCCs A
   ├─ Domain B
   │  └─ Profile B
   │     └─ UCCs B
   └─ Domain C
      └─ Profile C
         └─ UCCs C

Engineering, research, compliance, operations, finance, procurement, and customer service may require very different knowledge and outcomes. AAR's hypothesis is that these differences can be expressed through their own Profiles and UCCs without changing its fundamental principles.

Generality test

Can a new domain be represented by a new Profile and new UCCs without changing the Kernel's common rules?

10. How the architecture creates trust

Regulating does not mean deciding everything in advance. It means making observable the elements that allow an operation to be understood and evaluated.

A regulated execution must make it possible to identify:

which UCC was active;
which rules and policies applied;
which inputs were authorized;
which controls were considered;
which outcome was produced;
why the operation was completed, blocked, or returned;
which continuity was enabled.

This visibility promotes:

modularity: complex capabilities can be divided into clear responsibilities;
traceability: operation, contract, and outcome can be related to one another;
isolation: one UCC does not silently correct or absorb another;
cognitive freedom: the LLM can handle situations that were not enumerated;
explicit control: authority, limits, and continuity remain clear;
specialization: different domains use the same foundation with their own policies;
evolution: components can change without rebuilding the entire system.

The execution record must cover contracts, events, and outcomes. It does not require disclosure of the LLM's internal chain of reasoning.

11. Simplicity and maturity

The architecture should contain the smallest set of concepts necessary to produce useful autonomy, bounded responsibility, verifiable outcomes, and governable continuity.

A new structure should be introduced only when it represents a distinct function that cannot be expressed through the existing elements.

AAR's maturity can be evaluated through simple questions:

Does each UCC have a recognizable responsibility?
Are scope and authority explicit?
Can an incomplete outcome be identified?
Does closure produce a clear state?
Can UCCs be combined without hidden responsibility?
Can different domains fit within the same architecture?
Can a shared policy be changed without repeating rules across every unit?

The more consistently these questions can be answered, the stronger the evidence that the architecture is general, understandable, and governable.

12. Synthesis

The Regulated Agentic Architecture organizes capabilities executed by LLMs through explicit contracts.

The Kernel provides the common rules. The Profile brings together the shared policy. The UCC defines an operation. The LLM interprets the contract, executes the capability, and produces an outcome with identifiable continuity.

In its algorithmic formulation, AAR prepares and validates the conditions of the operation without programming the reasoning used by the LLM to solve it.

AAR in operation
├─ 1. Apply: Kernel
├─ 2. Specialize: Profile
├─ 3. Delimit: UCC
├─ 4. Execute: LLM
├─ 5. Produce: Outcome
└─ 6. Define: Continuity

Intelligence remains free to solve the problem; the architecture determines the contract under which that capability may operate.

Appendix — Conceptual execution algorithm

The algorithm below expresses the minimum functions of a regulated execution. It does not define a single implementation or turn the LLM into a deterministic executor.

ALGORITHM EXECUTE_UCC

INPUTS
- Kernel
- Profile
- UCC
- current state
- available sources, outcomes, and tools

1. COMPOSE THE CONTRACT
   1.1 load Kernel, Profile, and UCC
   1.2 check their compatibility
   1.3 apply the order of authority
   1.4 form the active contract

2. RESOLVE THE SCOPE
   2.1 identify the active route
   2.2 select only authorized inputs
   2.3 load permitted prior outcomes
   2.4 make authorized tools available

3. CHECK THE INITIAL CONDITIONS
   3.1 evaluate module controls
   3.2 identify impediments
   3.3 if there is an impediment:
       - produce the corresponding state
       - record the cause
       - terminate without publishing an invalid outcome

4. EXECUTE THE CAPABILITY
   4.1 present the contract and scope to the LLM
   4.2 move through the delivery cores in order
   4.3 allow freedom of reasoning within the contract
   4.4 form the candidate outcome

5. VALIDATE THE OUTCOME
   5.1 check mandatory deliverables
   5.2 verify completeness criteria
   5.3 verify local and general controls
   5.4 validate the content and form of publication

6. HANDLE AN INVALID OUTCOME
   6.1 identify the unsatisfied obligation
   6.2 apply only a predefined response:
       - limited retry
       - wait for information
       - block
       - return to another UCC
       - request a human decision

7. PUBLISH A VALID OUTCOME
   7.1 record the outcome
   7.2 assign identity and revision
   7.3 prevent silent alteration

8. DEFINE CONTINUITY
   8.1 determine the resulting state
   8.2 identify the next permitted transition
   8.3 enable the next UCC, return, or terminate

9. RECORD THE EXECUTION
   9.1 record the applied contract
   9.2 record the inputs used
   9.3 record the controls evaluated
   9.4 record the published outcome
   9.5 record the state and continuity

OUTPUTS
- published outcome or state without publication
- new state
- next permitted transition
- execution record

In compact form:

EXECUTE_UCC(Kernel, Profile, UCC, State):

    Contract ← compose(Kernel, Profile, UCC)

    if Contract is incompatible:
        return INVALID_CONFIGURATION

    Scope ← resolve_authorized_inputs(Contract, State)

    Condition ← evaluate_initial_controls(Contract, Scope)

    if Condition prevents execution:
        return corresponding_state(Condition)

    Candidate ← LLM.execute(Contract, Scope)

    Validation ← validate(Candidate, Contract)

    if Validation fails:
        return handle_failure(Validation, Contract)

    Outcome ← publish(Candidate)

    NewState ← resolve_continuity(
        Contract,
        Outcome,
        State
    )

    record_execution(
        Contract,
        Scope,
        Outcome,
        NewState
    )

    return Outcome, NewState