Contact us

FUURAA AI Civilization Architecture

Agent Operating Layer Reference Architecture

Connect identity, memory, permissions, orchestration, safety governance and interoperability into one reviewable action chain: every external action should begin with a known subject and authority, execute through a bounded plan, and end with handoff-ready evidence.

Public statusResearch direction · architecture referenceEvidence statusSynthesis grounded in public standardsSources checked4 August 2026

Minimum action chain

Authority is not one check; it is a chain that must remain valid.

A model proposing an action does not mean the system is authorised to execute it. The operating layer must preserve and re-evaluate boundaries through planning, tool use, delivery and retention.

  1. 01

    Identify

    Resolve subject, principal and authentication context.

  2. 02

    Authorise

    Evaluate capability, resource, purpose, expiry and approvals.

  3. 03

    Plan

    Freeze steps, contracts, budgets, checkpoints and rollback.

  4. 04

    Execute

    Re-check policy at consequential boundaries and record outcomes.

  5. 05

    Prove

    Join provenance, decisions, outputs, exceptions and review state.

FUURAA analysisReusable Agent infrastructure is not a larger set of tools that can always be called. It is a way for every capability to travel with a resolvable subject, least privilege, expiry, plan boundary and evidence requirement. Operating-layer value should be measured by safe denial, revocation, recovery and review—not task completion alone.

Six cross-cutting disciplines

Every layer needs interfaces, an evidence gate and a stop condition.

This is a public reference architecture, not a statement that FUURAA products implement these capabilities. Each system requires new design and validation for its risk, region, sector and affected people.

01

Identity

Who or what is acting, and which principal is accountable?

Bind each person, organisation, Agent, service and device to a stable runtime subject without assuming that one identifier proves every real-world attribute.

Minimum interfaces
  • Subject identifier and subject type
  • Delegating principal and authentication event
  • Credential, service or device assertions with issuer and validity
Evidence gate

The runtime can distinguish subject identity, authentication strength, asserted attributes and delegated authority in the decision log.

Stop condition

Do not execute when the acting subject, delegating principal or assertion validity cannot be resolved.

02

Memory & provenance

What may persist, where did it come from and when must it expire?

Separate working context, episodic records, durable knowledge and learned preferences so retention, consent, correction and deletion can be governed by memory class.

Minimum interfaces
  • Memory class, source entity and producing activity
  • Purpose, consent basis, sensitivity and permitted readers
  • Created, reviewed, superseded and expiry timestamps
Evidence gate

Every durable item has provenance, an owner, a retention rule and a tested path for correction or deletion across indexes and caches.

Stop condition

Do not promote transient context into durable memory when purpose, authority, provenance or retention is unknown.

03

Permissions

Which capability, resource, action and time window are allowed?

Evaluate each requested action against explicit, least-privilege policy rather than trusting a session, network location or broad tool connection.

Minimum interfaces
  • Capability, action, resource and field-level scope
  • Policy version, risk class, expiry and revocation handle
  • Human-approval requirement and separation-of-duty role
Evidence gate

Policy decisions are deny-by-default, versioned, explainable and tested for revocation before consequential tools are enabled.

Stop condition

Block actions whose requested scope exceeds the delegated capability or whose policy context is stale.

04

Orchestration

How are models, tools, workflows and people coordinated and recovered?

Turn an approved objective into bounded steps with explicit inputs, tool contracts, budgets, checkpoints, retries, rollback and human escalation.

Minimum interfaces
  • Objective, plan version, step graph and tool contract
  • Time, token, cost, data and action budgets
  • Checkpoint, idempotency key, rollback and escalation state
Evidence gate

A dry run and fault-injection suite demonstrate bounded retries, duplicate-action prevention, safe cancellation and resumable checkpoints.

Stop condition

Stop when the plan changes material scope, a tool contract drifts, budgets are exhausted or rollback is unavailable.

05

Safety & governance

Which risks, evaluations, owners and incident paths constrain operation?

Connect system context and risk decisions to evaluation, monitoring, accountable human roles, incident response and change control throughout operation.

Minimum interfaces
  • Use-case boundary, affected parties and risk register
  • Evaluation suite, thresholds and monitoring signals
  • Accountable owner, incident route and change approval
Evidence gate

Release claims map to dated evidence, named owners, failure thresholds and a tested incident and rollback procedure.

Stop condition

Suspend operation when monitoring coverage, accountable ownership or an applicable risk control is missing or invalidated.

06

Interoperability

How can systems connect without losing authority, meaning or evidence?

Use versioned contracts and portable evidence envelopes so a receiving system can interpret subject, scope, data semantics, policy and provenance without inheriting implicit trust.

Minimum interfaces
  • Protocol, schema, vocabulary and version identifiers
  • Capability negotiation and unsupported-feature response
  • Trace context, provenance links and conformance evidence
Evidence gate

Contract tests cover version skew, unknown fields, partial failure, credential rejection and end-to-end trace continuity.

Stop condition

Do not bridge systems when semantics, authority or provenance are silently downgraded during translation.

Minimum request envelope

Make the action request decidable before a model decides how to complete it.

Field names are a FUURAA public reference, not a normative protocol. Implementations may use another schema, but should not silently lose these semantics.

subject_id

subject id

Stable runtime subject; never a substitute for all real-world identity claims.

delegating_principal

delegating principal

Person, organisation or service granting the bounded capability.

capability + scope

capability + scope

Named action, resource, fields, limits and excluded operations.

purpose + context

purpose + context

Why the action is requested and which use-case boundary applies.

policy_version

policy version

Exact policy evaluated, decision outcome and required approvals.

expiry + revocation

expiry + revocation

Short validity window and a usable path to revoke authority.

plan + tool_contract

plan + tool contract

Versioned step graph, tool schema, budgets and rollback behaviour.

trace_id + evidence

trace id + evidence

Decision, execution, output, exception and review records joined end to end.

Failures to seek deliberately

The most dangerous failures often occur between layers.

Passing component tests does not establish a reliable composed action chain. Testing should target breaks between authority, memory, plans, tools and evidence.

F1

Confused authority

A valid identity is treated as permission to perform an unrelated action.

F2

Memory without a lifecycle

Transient or sensitive context becomes durable, copied and difficult to correct or delete.

F3

Permission drift

A long-running workflow continues after policy, role, credential or operating context changes.

F4

Duplicate consequence

Retries or recovery repeat an external action because idempotency and checkpoints are missing.

F5

Evidence discontinuity

The result survives but the model, prompt, tool response, policy decision or human approval cannot be reconstructed.

F6

Silent semantic downgrade

A bridge accepts unknown fields or weaker credentials without making the loss visible to the receiver.

Minimum engineering evidence package

The deliverable is not only an output, but decisions and boundaries a recipient can review.

Package completeness cannot establish truth, correctness or safety; it only creates the minimum relationships needed for review.

01

System and subject baseline

Runtime release, models, tools, service and device identities, credential issuers and delegating principals.

02

Policy and memory baseline

Permission policies, memory classes, consent and retention rules, indexes, deletion paths and version hashes.

03

Evaluation and fault evidence

Nominal, adversarial, expired-authority, tool-drift, duplicate-action, partial-failure and recovery results.

04

Runtime decision trail

Requested objective, plan, policy decision, approvals, tool calls, outputs, exceptions and final disposition.

05

Release and incident record

Applicable boundary, accepted residual risks, accountable owner, monitoring, rollback, incident and next-review trigger.

Applicability boundary

Use this page for early system architecture, interface review, threat modelling and evidence planning. It is not legal, privacy, cybersecurity or sector-compliance advice; it does not disclose unannounced FUURAA product capabilities; and using these fields or sources does not establish a safe autonomous system. High-impact or physical action requires use-case-specific professional accountability, local requirements and independent validation.

Primary sources and evidence boundaries

Use standards language without presenting a reference architecture as conformance.

Each source states its publication date, role in this architecture and what cannot be inferred from it.

Published 1 August 2025

NIST SP 800-63-4 · Digital Identity Guidelines

Primary reference for identity proofing, authentication, federation and assurance language.

BoundaryWritten for users interacting with government information systems; it does not define a complete identity model for autonomous Agents.

Open primary source ↗Published August 2020

NIST SP 800-207 · Zero Trust Architecture

Supports resource-centred, continuously evaluated access decisions instead of implicit network trust.

BoundaryAn enterprise cybersecurity architecture, not an Agent permission schema or product certification.

Open primary source ↗W3C Recommendation · 30 April 2013

W3C PROV-DM · The PROV Data Model

Provides the entity, activity and agent concepts used to reason about how records were produced.

BoundaryA general provenance model; implementation still needs domain vocabulary, security, retention and verification rules.

Open primary source ↗W3C Recommendation · 15 May 2025

W3C Verifiable Credentials Data Model v2.0

A machine-verifiable, privacy-aware data model for issuer, holder and verifier credential relationships.

BoundaryA credential data model does not prove that an issuer is trustworthy or that a presented claim authorises an Agent action.

Open primary source ↗Published 26 January 2023

NIST AI RMF 1.0

Connects governance, context mapping, measurement and risk management across the AI lifecycle.

BoundaryVoluntary, non-sector-specific guidance; implementation evidence and sector obligations remain the operator’s work.

Open primary source ↗Published 26 July 2024 · source updated 8 April 2026

NIST AI 600-1 · Generative AI Profile

Adds generative-AI-specific risks and actions to the AI RMF lifecycle approach.

BoundaryA cross-sectoral profile, not proof that a runtime is safe, compliant or suitable for a named deployment.

Open primary source ↗

Continue

Move from reference architecture into domains, evidence method and public progress.

Return to AI Civilization ArchitectureEnter the Agent Systems build domainRead the AI evidence-literacy guideReview public company progress