Product architecture should separate what the team is trying to achieve, what it may do and how the organisation controls the result.
In brief
An operating layer connects a business mission to roles, context, tools and controls. Before deployment, require six distinct capabilities: identity, mandate, context, orchestration, tool access and evidence. When any capability remains implicit, the system becomes harder to govern, recover and improve.
This is an editorial architecture framework, not a contractual list of Atlensia product features.
Six capabilities to keep distinct
| Capability | Product question | Evidence to inspect |
|---|---|---|
| Identity | Who acts and for which function? | Dedicated identity, role, human owner |
| Mandate | Which outcome is expected? | Objective, exit criteria, excluded cases |
| Context | Which information matters now? | Authorised sources, freshness, provenance, working memory |
| Orchestration | How does work move between roles? | State, priorities, handoffs, error recovery |
| Tool access | Which actions are allowed? | Least privilege, limits, idempotency, revocation |
| Evidence | How can the result be understood? | Records, approvals, metrics, rule versions |
The Atlensia platform presents autonomous teams as coordinated roles integrated with tools and bounded by organisational rules. This places work architecture before model selection.
A three-plane architecture
The decision plane contains the mandate, priorities and policies. The orchestration plane manages work state, roles and handoffs. The execution plane calls tools and data. Controls cross all three planes: identity, permission, approval, records, cost limits and stop mechanisms.
This separation localises change. Replacing a model should not redefine rights. Adding a connector should not alter the mandate. Changing an approval policy should not erase the history of prior decisions.
Treat context as a managed resource
Useful context is not every document the organisation can retrieve. It is the bounded set of facts, policies and business objects required for the current task. Every critical element should have a source, date, owner and validity period.
Three compartments reduce ambiguity:
- Reference context holds stable rules and approved versions.
- Case context holds information specific to the item being handled.
- Working memory holds temporary steps, hypotheses and intermediate results.
A hypothesis must not become reference data silently. Moving information between compartments requires a rule or approval.
Design handoffs as contracts
A handoff is more than a message between agents. It should identify the transferred object, achieved state, completed checks, missing information, next responsibility and escalation condition.
| Handoff field | Example |
|---|---|
| Object | Supplier case 2026-184 |
| State | Documents checked, amount extracted |
| Evidence | Contract, invoice, supplier register |
| Uncertainty | Cost centre missing |
| Next owner | Finance control |
| Escalation | Procurement owner above the amount threshold |
This structure supports incident recovery and prevents a role from inheriting a conclusion without knowing how it was reached.
Decouple models from policies
Models change, while enterprise policies must remain readable and testable. Access rights, approval thresholds, retention rules and cost limits should not exist only inside an instruction sent to a model.
The NIST AI Risk Management Framework provides a useful structure connecting governance, impact mapping, measurement and treatment. For authorisation, RFC 9700 consolidates current OAuth 2.0 security practice. Both support the same architectural principle: keep policy decisions separate from technical execution.
Test degraded modes
Product architecture is also defined by what happens when something is missing. Test at least an unavailable source, contradictory data, slow connector, API rate limit, unavailable model, unanswered approval and access revoked during a task.
For every case, the system should explicitly retry, wait, escalate or stop. Continuing with incomplete context should not be the default.
Pre-deployment selection grid
Ask for verifiable demonstrations of six points:
- one identity and human owner for every role;
- a versioned mandate with excluded cases;
- visible provenance for critical context;
- a reconstructable handoff between two roles;
- a permission that can be revoked without disabling the whole platform;
- an evidence chain connecting input, rule, action, approval and output.
Then add business-specific requirements such as data residency, encryption, recovery, cost, latency, integration and retention.
Conclusion
A sound operating layer does not hide operational complexity. It makes that complexity explicit, attributable and testable. Start by drawing the three planes and six capabilities for one real workflow. Any box without an owner, evidence or policy becomes a design requirement before deployment.