MyOpsAgent Architecture Overview

1. Architectural Principles

MyOpsAgent is built on five core principles:

1. Determinism

The same inputs always produce the same outputs. This is essential for:

• Auditability
• Compliance
• Debugging
• Trust

2. Explainability

Every decision includes a breakdown of weighted reasoning factors. This ensures transparency, supports regulatory requirements, and allows stakeholders to understand why a particular decision was made.

3. Multi-Tenant Isolation

Each organisation is fully isolated at multiple levels:

• API keys
• Usage limits
• Audit logs
• Decisions
• Data access

This allows MyOpsAgent to safely support thousands of organisations on a single platform without cross-tenant data leakage.

4. API-First Design

The entire platform is accessible through a clean, consistent API. This enables:

• Easy integration
• Automation
• UI independence
• SDK development

5. Operational Resilience

The system is designed to:

• Fail gracefully
• Enforce limits
• Log every decision
• Provide health checks
• Scale horizontally

2. High-Level Architecture

MyOpsAgent consists of five major layers:

A. Decision Engine (Core Brain)

This is the heart of the platform. It is:

• Stateless
• Deterministic
• Explainable
• Domain-driven
• Independent of HTTP, databases, or authentication

The engine evaluates:

• Work item requirements
• Resource capabilities
• Constraints
• Context
• Organisational rules

It produces:

• Chosen resource
• Confidence score
• Reasoning factors
• Decision metadata

Because the engine is stateless, it can scale horizontally without coordination, making it ideal for high-throughput environments.

B. Application Layer

This layer orchestrates the engine and handles:

• Input validation
• Domain object construction
• Use case execution
• Response formatting

Key components include:

• ExecuteDecisionUseCase
• DecisionController

This layer ensures that the engine receives clean, validated, domain-correct inputs and that responses are returned in a consistent, predictable format.

C. Infrastructure Layer

This layer handles all external concerns:

• MySQL persistence
• Audit logging
• Usage metering
• API key management
• Correlation ID generation

It includes components such as:

• MysqliDecisionRepository
• AuditLogger
• UsageTracker
• API Key Store

This layer ensures that decisions are stored, tracked, and auditable, supporting compliance and operational analytics.

D. API Gateway

This is the public entry point for all requests. It handles:

• Routing
• Authentication
• Rate limiting
• Usage enforcement
• Error handling
• Correlation IDs

It ensures that:

• Only valid requests reach the engine
• Each organisation is isolated
• Limits are enforced
• Errors are returned in a structured format

E. Operational Layer

This layer provides:

• /health endpoint
• /version endpoint
• Monitoring hooks
• Structured logs
• Performance metrics

It ensures that MyOpsAgent remains observable and reliable, enabling proactive monitoring and incident response.

3. Multi-Tenancy Model

MyOpsAgent uses a strict isolation model:

• Each organisation has its own API keys
• Each key maps to exactly one organisation
• All decisions are tagged with org_id
• Usage is tracked per organisation
• Audit logs are scoped per organisation

This allows:

• Safe multi-tenant hosting
• Per-organisation billing
• Per-organisation rate limits
• Per-organisation compliance

No customer can ever access another customer’s data. This isolation model is foundational to the platform’s security and trust posture.

4. Decision Flow (Step by Step)

This section explains exactly what happens when a customer calls the /decide route.

Step 1 — Request Received

The API gateway receives a POST request with:

• X-API-Key header
• JSON payload

A correlation ID is generated immediately.

Step 2 — Authentication

The API key is validated:

• Does it exist?
• Is it active?
• Which organisation does it belong to?

If invalid, the request is rejected with an UNAUTHORIZED error.

Step 3 — Usage Enforcement

The system checks:

• Per-minute rate limit
• Daily usage cap
• Monthly usage cap

If exceeded, the request is rejected with RATE_LIMITED or HARD_USAGE_LIMIT_EXCEEDED.

Step 4 — Input Validation

The JSON payload is validated for:

• Required fields
• Correct types
• Non-empty arrays
• Valid domain structure

Invalid requests return an INVALID_INPUT error.

Step 5 — Domain Construction

The system constructs domain objects:

• WorkItem
• Resource objects
• Constraints
• Context

These are passed to the engine.

Step 6 — Engine Execution

The engine:

• Evaluates capabilities
• Scores resources
• Applies constraints
• Calculates confidence
• Selects the best resource

This step is deterministic and stateless, ensuring consistent behaviour across identical inputs.

Step 7 — Decision Logging

The decision is stored with:

• Decision ID
• Organisation ID
• Work item ID
• Chosen resource
• Reasoning factors
• Timestamps
• Correlation ID

This enables full auditability and traceability.

Step 8 — Usage Increment

The organisation’s usage counters are updated:

• total_requests
• decisions_count
• updated_at

Step 9 — Response Returned

The API returns:

• Chosen resource
• Confidence
• Reasoning factors
• Decision ID
• Correlation ID
• Duration

All in a clean, structured JSON response.

5. Scaling Strategy

MyOpsAgent is designed to scale in two dimensions:

A. Scaling for Small Organisations

Small businesses typically:

• Have fewer resources
• Make fewer decisions
• Require simple integrations

MyOpsAgent supports them with:

• Simple API keys
• Low overhead
• Minimal configuration
• Fast onboarding

B. Scaling for Large Enterprises

Enterprises require:

• High throughput
• Strict auditability
• Multi-region operations
• Compliance
• Deterministic behaviour
• Usage metering
• Key rotation
• Integration with existing systems

MyOpsAgent supports this through:

• Stateless engine
• Horizontal scalability
• Strict multi-tenant isolation
• Structured logs
• Correlation IDs
• Usage tracking
• Rate limiting

6. Future Roadmap

The architecture is designed to support future enhancements, including:

• Webhooks
• Decision replay
• SLA monitoring
• Rule versioning
• Async job queues
• Bulk decisioning
• UI dashboards
• SDKs for major languages

These features can be added without changing the core engine, preserving determinism and stability.

Conclusion

MyOpsAgent’s architecture is designed for reliability, transparency, and scale. By separating concerns into clear layers — engine, application, infrastructure, gateway, and operations — the platform remains flexible, maintainable, and ready for future growth.

This architecture allows MyOpsAgent to serve:

• Small teams needing simple automation
• Large enterprises requiring compliance and auditability
• Everything in between

It is a modern, scalable foundation for operational decision making.