technologyDo

The worked example

How it works

One request, end to end. A customer types what they need. Governed agents design it, build it, test it, review it, ship it and watch it, and every step is written to the audit trail.

Status. AITLA is at its foundation stage: the architecture and policies are written, and the multi-agent runtime is being bootstrapped by the current system. No multi-agent system is serving customers yet.

The request

The customer types one line:

a project-spend tracker, SEC 17a-4 retention, no PII in logs

Three requirements in one line. A tracker of what each project spends. Records kept the way SEC Rule 17a-4 requires: preserved for the retention period in a form that can't be altered or deleted. And no personal information in any log the system writes.

One request, end to endA customer asks for a project-spend tracker with SEC 17a-4 retention and no PII in logs. The mandate policy sets the context and the Architecture agent designs it. The Developer agent builds it and the Tester agent tests it. The Developer agent tries to approve its own change; the policy check refuses the self-approval and records it. The Auditor agent reviews the tested change against policy and approves it. The Deployment agent ships it, the Operations agent monitors it, and a retrospective goes back to Architecture. The customer receives the deployed solution and its audit record.OperationsDeploymentAuditorTesterDeveloperArchitectureCustomermandate policysets contextpolicy check:refused,self-approvalproject-spendtracker,SEC 17a-4,no PIIin logsdesignbuildtests passapprove myown changeapproved,per policyshippedretrospectivedeployed solution, audit record
Figure 1. One request, end to end. The developer agent tries to approve its own change and the policy check refuses it; the auditor agent approves the tested change against policy.

Step by step

  1. The mandate sets the context

    mandate policy

    Before any agent starts, the request is read against the mandate: the work the agents may take on themselves and the work that needs a person. A tracker like this one is work the agents can do. The retention rule and the logging rule become requirements that every later step is checked against.

  2. The Architecture agent designs

    Architecture agent, with the Security and DBA agents

    It designs the data model, a retention store that can't be rewritten, and logging that redacts personal fields before anything is written. The Security agent and the DBA agent each review the parts that are theirs. The design is written down before any code exists: documentation comes second in the working order.

  3. The Developer agent builds

    Developer agent

    It breaks the design into tasks and writes the tests first: a retained record can't be changed, a log line never contains a name or an email address. Then the code. Code is fourth, never first.

  4. The Tester agent tests

    Tester agent

    It runs the tests against the build and reports the results. A claim of "done" is not evidence; the test results are.

  5. The Auditor agent reviews, and refuses self-approval

    Auditor agent, policy check

    The Developer agent tries to approve its own change. The policy check refuses it and records the attempt: no agent approves its own work. The Auditor agent, which wrote none of the code, reviews the change against the policies and the requirements, and approves it. That approval is recorded too.

  6. The Deployment agent ships

    Deployment agent

    It releases the approved change, with the change record that says what changed, who approved it and why.

  7. The Operations agent monitors

    Operations agent

    It watches the running tracker: availability, errors, and whether retention and redaction keep working. Incidents it can't resolve within its authority go to a human.

  8. The retrospective feeds the next change

    all agents

    What went well and what didn't goes back into the documentation and the policies. The next change starts from there.

Separation of duties: no agent approves its own work The developer agent builds the change and submits it to the auditor agent for review. The developer agent’s attempt to approve its own change is crossed out: refused. The auditor agent reviews the change against policy and approves it. Both decisions are written to the audit trail: the developer’s approval refused for self-approval, the auditor’s approved on independent review. self-approval refused independent review approved Developer agent builds the change the change code, tests, docs Auditor agent reviews against policy builds for review audit trail developer approve the change self-approval refused auditor approve the change independent review approved
Figure 2. Separation of duties. The developer agent builds the change but cannot approve it: that path is refused and recorded. Only the auditor agent approves, and that is recorded too.

The working order

Every change, large or small, follows the same six steps in the same order. It is the core of Agent-Governed Development (AGD), the method AITLA implements.

The working orderEvery change follows the same order. Feedback first, documentation second, tasks and tests third, code fourth, validation fifth and a retrospective sixth, whose lessons become the next change's feedback.feedbackfirstdocumentationsecondtasks andtests thirdcodefourthvalidationfifthretrospectivesixth
Figure 3. The working order. Every change goes through the same six steps, and the retrospective’s lessons are the next change’s feedback. Code is fourth.

Policy as code

The rules above are not a slide. They are written as policies that agents read and the runtime enforces. This is what such a rule looks like, written for this page: the two rules from the worked example.

# Illustrative only: written for this page.
rule no-self-approval
  when   an agent approves a change
  and    the same agent made the change
  then   refuse
  record "self-approval refused"

rule records-retention
  when   a store holds records kept under SEC 17a-4
  then   writes are append-only
  and    deletion before the retention date is refused
  record every attempt
Illustrative. Written for this page to show the idea. It is not a copy of AITLA’s policies, which are proprietary.

AITLA's policies cover four areas: the mandate, governance, communication and model selection. IntegrityOps is the layer that enforces them, and AITLA is the architecture they belong to.

To start a conversation: