Architecture · Public Overview
MyOpsAgent Architecture Overview
MyOpsAgent is designed as a layered business intelligence and decision platform. The architecture keeps natural-language interaction separate from identity, permissions, authoritative business state, controlled tools and deterministic decision logic.
This public overview explains the responsibilities of those layers without publishing private infrastructure, credentials, internal file structures or security-sensitive implementation detail.
1. Architectural Principles
Business state is authoritative
Connected data, organisation configuration, rules, capabilities and recorded operational state are treated as the source for controlled workflows. Generated narrative does not replace authoritative business data.
Language and authority are separate
Conversational AI can understand requests and explain results. Permission checks, constraint evaluation, deterministic decisions and approval rules are enforced outside the language model.
Least privilege by default
A tool, dataset or action is available only when the organisation, user and active module are allowed to use it.
Organisation isolation
Organisation-scoped data, credentials, configuration, usage and tools are separated so one tenant cannot intentionally use another organisation's context.
Traceable change
Important operational decisions can be recorded with the state, constraints, recommendation, approval, execution and verification events needed to understand what happened.
2. High-Level Platform Layers
A. Experience Layer
Provides the conversational agent, public website experience, authenticated business console and organisation-specific interfaces through which users ask questions or initiate approved workflows.
B. Identity & Access Layer
Establishes who is asking and which organisation, role, module, information and actions are available. Public access and authenticated internal access are deliberately different trust levels.
C. Knowledge & Context Layer
Supplies approved company information and connected context required to answer a question or evaluate a workflow. Context may include documents, configuration and current operational state.
D. Tool & Integration Layer
Makes approved capabilities available to the agent and platform. Tools are registered, scoped and permission-aware rather than giving a language model unrestricted access to backend systems.
E. Operational State Layer
Represents business entities and current state relevant to controlled decisions, such as work, people, assets, projects, capabilities, allocations, events and other organisation-specific records.
F. Decision & Consequence Layer
Evaluates rules, capabilities, dependencies and constraints when an operational question requires a controlled answer. Where deterministic logic is used, identical governed inputs and rule versions can be replayed to reproduce the same decision result.
G. Approval, Execution & Verification Layer
Separates recommendation from authority to act. A workflow can stop for approval, execute an authorised change through an approved tool, and verify the resulting state before the decision is considered complete.
H. Audit & Observability Layer
Records relevant platform events, decisions, tool activity, outcomes and diagnostic identifiers so the organisation can investigate behaviour and maintain operational accountability.
3. Typical Request Flows
Knowledge or status question
- A user asks a question in natural language.
- Identity, organisation and access scope are resolved.
- Approved knowledge or current business context is retrieved.
- The conversational layer explains the answer using the permitted context.
Controlled operational change
- A real or proposed change is recorded against authoritative operational state.
- The platform identifies affected work, resources, dependencies or constraints.
- Controlled decision logic evaluates valid alternatives and consequences.
- A recommendation is created with supporting reasoning and risk information.
- The workflow stops for approval where policy requires it.
- An approved action is executed only through an authorised capability.
- The resulting state can be verified and recorded.
4. Multi-Tenant Boundaries
MyOpsAgent is multi-tenant by design. Organisation context is carried through platform operations so data access, configured tools, enabled modules and operational records can be evaluated inside the correct tenant boundary.
Public documentation intentionally does not publish private schema layouts, infrastructure topology, credential formats or administrative control paths.
5. Integration Strategy
Integrations are added where they provide a clear business benefit. MyOpsAgent can sit above existing systems, retrieve approved context or carry out permitted actions without requiring the organisation to replace every system it already uses.
Integration capability is organisation- and module-specific. Exact endpoints, scopes and credentials should be taken from the organisation's authenticated integration configuration rather than copied from public examples.
6. Security Boundary
- Do not treat generated text as permission to perform an action.
- Do not expose server credentials in browser code.
- Use organisation-scoped credentials and rotate them when required.
- Apply domain restrictions to browser-facing integrations where supported.
- Require human approval for workflows whose risk or governance warrants it.
- Keep internal deployment and administrative documentation outside the public documentation area.