The runtime changes. The architectural responsibilities do not disappear.
E2A is a vendor-neutral architecture framework for applying enterprise engineering discipline to Agentic AI systems.
It focuses on the boundary where probabilistic reasoning meets deterministic enterprise execution: identity, tenancy, policy, state, tools, systems of record, reliability, observability, cost, evaluation, and confirmed physical outcomes.
Core thesis: Probabilistic intelligence may propose an action. Deterministic enterprise controls must authorize, execute, and confirm material outcomes.
E2A did not start as a top-down attempt to invent an Agentic AI framework.
It emerged from architectural spike work used to test whether enterprise-grade reliability and transaction-integrity patterns could survive the transition into cloud-native distributed systems and Agentic AI runtimes.
The spikes repeatedly surfaced the same responsibilities:
- Explicit contracts
- Deterministic state boundaries
- Identity and authorization
- Idempotency and concurrency control
- Failure isolation and recovery
- Reconciliation and compensation
- Observability and auditability
- Governed integration boundaries
- Explicit execution context
The implementation technologies changed substantially, but the architectural responsibilities remained recognizable.
That observation became the initial E2A hypothesis:
The runtime changes. Enterprise engineering invariants must be re-expressed for the new runtime rather than discarded.
Enterprise Engineering Experience
|
v
Architectural Spikes
|
v
Cross-runtime invariant discovery
|
v
E2A
|
+------+------+
| |
v v
A2C P0
| |
+------+------+
|
v
G2C
|
v
E2A extensions/profiles
/ \
v v
Deterministic CQRS AI-DLC
The spikes therefore have two roles in the history of the work:
- Discovery spikes helped reveal and challenge the structural continuity that led to E2A.
- Reference runtimes exercise and refine formal framework patterns after those patterns are defined.
This repository uses careful evidence language throughout. Architectural feasibility, reference-runtime validation, and actual production evidence are not treated as interchangeable.
Traditional systems of record operate primarily under deterministic correctness expectations:
- Explicit authorization
- Known state transitions
- Idempotency
- Concurrency control
- Transactional persistence
- Reliable event publication
- Auditability
- Recovery and reconciliation
Agentic systems introduce another correctness model:
- Probabilistic reasoning
- Retrieved context
- Model and prompt variability
- Tool selection
- Confidence and groundedness
- Iterative execution
- Token and model cost
The objective is not to force probabilistic components to become deterministic transaction processors.
The objective is to establish an explicit boundary between the two correctness models.
DETERMINISTIC ENTERPRISE WORLD
identity | policy | data | transactions | audit
|
v
+--------------------+
| E2A CONTROL |
| context |
| orchestration |
| governance |
| evaluation |
| observability |
+--------------------+
|
v
PROBABILISTIC AI WORLD
agents | LLMs | RAG | planning | tool selection
|
proposed action
|
v
deterministic authorization
+ execution + confirmation
|
v
SYSTEM OF RECORD
A model response or tool invocation is not automatically a successful business transaction.
A material effect should be declared successful only after the evidence required by the business contract has been confirmed.
E2A is the runtime and governance core of a broader architecture R&D family.
| Framework / profile | Primary responsibility |
|---|---|
| P0 | Project, platform, configuration, and engineering scaffolding |
| G2C | Governed contract synthesis; Generate-to-Class is the initial concrete realization |
| E2A | Runtime orchestration, agents, RAG, tools, policy, enterprise integration, and execution context |
| A2C | Policy-aware generation of code, tests, configuration, IaC, and delivery artifacts |
| AI-DLC | Static and runtime evaluation and assurance across the lifecycle |
| Deterministic CQRS Profile | Transactional commands, scalable queries, outbox, idempotency, concurrency, and compensation |
BUSINESS / ARCHITECTURE INTENT
|
v
P0
|
v
G2C
|
+-----+-----+
| |
v v
A2C E2A
| |
+-----+-----+
|
v
AI-DLC
CQRS is applied where deterministic transactional
semantics require stronger guarantees.
Historical evolution and runtime composition are intentionally different views. E2A appeared first historically; P0 and G2C can execute earlier in a solution lifecycle.
Important controls should be encoded into architecture contracts rather than repeatedly rediscovered inside individual application implementations.
Examples include:
- Lifecycle ordering
- Required execution context
- Authorization boundaries
- Idempotency
- Evaluation gates
- Tool contracts
- Observability
- Failure classification
- Deterministic confirmation of material effects
Availability, latency, security, reliability, auditability, cost, AI quality, and recovery should be treated as architecture inputs with explicit enforcement points and measurable evidence.
Core framework capabilities expose a stable public lifecycle entry point that owns cross-cutting behavior and sequencing.
Domain-specific implementations specialize through bounded extension hooks instead of taking ownership of the entire lifecycle.
Execution state is propagated explicitly rather than stored implicitly on long-lived agent instances.
Representative dimensions include:
- Correlation / trace identity
- Tenant
- User or workload identity
- Idempotency context
- Policy context
- Runtime configuration
- Business context
- Failure and compensation metadata
Domain and execution contracts should avoid unnecessary exposure to provider SDK semantics.
Portability therefore means stable contracts with replaceable provider realizations, not an assumption that AWS, Google Cloud, and Microsoft Azure services are identical.
Reasoning, tool selection, and transport-level success are not sufficient evidence that a material business outcome occurred.
For high-impact actions, E2A expects deterministic confirmation appropriate to the system of record and business contract.
One of the ideas behind E2A is structural isomorphism: recurring architectural responsibilities can remain aligned across code contracts, runtime control flow, and deployment topology even when technologies change.
This does not claim literal equivalence between technology constructs.
An SAP Behavior Definition is not literally a Python BaseAgent; an OData service is not literally FastAPI. The useful observation is that they can occupy comparable responsibilities in their respective runtime architectures.
| Code / architecture concept | Runtime responsibility | Typical realization |
|---|---|---|
| Public template method | Controlled lifecycle entry | API/service/workflow endpoint |
| Protected extension hook | Domain specialization | Private application/agent logic |
| Private framework mechanism | Governed platform behavior | Adapter / platform capability |
| Explicit execution context | Causality, identity, and tenancy | Trace / identity / state propagation |
| Evaluation gate | Quality / release decision | Evaluator / critic / pipeline gate |
| Compensator | Scoped recovery | Saga / workflow / reconciliation tier |
The cross-runtime comparison that contributed to the framework remains useful when read as architectural correspondence rather than technology identity.
| Architectural Layer | SAP RAP | Spring Boot | FastAPI/Python | Agentic Runtime |
|---|---|---|---|---|
| Data model | CDS View Entity | @Entity / DTO |
Pydantic model | Agent / workflow state |
| Interface contract | Behavior Definition | Java interface | Protocol / ABC | Base agent/workflow contract |
| Business logic | Behavior Implementation | @Service |
Concrete service | Agent + deterministic services |
| Callable operation | RAP Action | Transactional method | Route / service operation | Tool / command |
| Quality gate | Determination / validation | Aspect / validator | Middleware / decorator | Evaluator / critic gate |
| Exposure | Service Binding / OData | Controller | FastAPI route | Workflow endpoint |
| Async integration | Event framework | Kafka listener | Queue worker | Async workflow / conditional edge |
| Observability | Platform/runtime telemetry | Micrometer / Actuator | OTel / structured logging | Agent/tool/evaluation telemetry |
| Governance | Authorization / business rules | Security / policy | Policy layer | Model/tool/policy gate |
| Deployment | Platform transport | Container / Kubernetes | Cloud/container deployment | Governed cloud runtime |
→ Full reference: reference/mapping-tables.md
The point of the mapping is architectural continuity, not literal equivalence.
A representative production-oriented E2A engineering sequence is:
| Phase | What gets established | Why it comes early |
|---|---|---|
| 1. Scaffold | Repository structure, dependencies, hooks, conventions | Forces foundational decisions before feature code expands |
| 2. Infrastructure | Reproducible compute, networking, data, messaging, secrets | Makes the execution substrate explicit |
| 3. Observability | Structured logs, traces, metrics, SLO instrumentation | Makes behavior measurable before complexity grows |
| 4. CI/CD | Build, test, security, and evaluation gates | Makes quality enforceable rather than review-only |
| 5. NFR controls | Reliability, policy, security, cost, recovery | Makes production controls architectural |
| 6. Business logic | Agents, RAG, tools, and domain flows | Builds capability on the governed foundation |
→ Full methodology: reference/nfr-first-sequence.md
This is a reference methodology, not a requirement for every system. Simpler systems should remain simple.
A normalized E2A runtime centers on a small number of controlled abstractions.
Representative lifecycle:
run(...)
|
+-> validate state
+-> enforce policy
+-> build model/context input
+-> invoke model through governed routing
+-> evaluate output
+-> execute authorized action when appropriate
+-> confirm material side effects
+-> record telemetry
The public lifecycle remains stable. Domain-specific behavior is introduced through controlled extension points.
Coordinates stateful or multi-agent execution while maintaining explicit context, workflow ownership, terminal evaluation, and failure boundaries.
Separates ingestion, indexing, retrieval, generation, and evaluation responsibilities while preserving authorization, tenant scope, source lineage, and freshness.
Provides a transport-neutral contract for governed actions. REST and MCP are transports; neither replaces authorization, schema validation, reliability controls, idempotency, or physical confirmation.
Standardizes traces, metrics, structured logs, SLO evidence, and AI/runtime telemetry.
Provides policy enforcement across model, tool, security, cost, and execution constraints.
| Activity | Default character | Required control |
|---|---|---|
| Intent classification | Probabilistic | Confidence, schema, fallback |
| RAG retrieval | Mixed | Authorization, tenant scope, lineage, freshness |
| Plan generation | Probabilistic | Policy and contract validation |
| Tool recommendation | Probabilistic | Allowlist and authorization |
| System-of-record mutation | Deterministic | Idempotency, concurrency, transaction control |
| Material success declaration | Deterministic | Verified physical outcome |
| Natural-language explanation | Probabilistic | Evidence and policy constraints |
This separation is central to E2A.
Agentic systems still depend on conventional distributed-systems patterns for the portions of a workflow that change material business state.
Optimizes for correctness and controlled mutation:
- Validation and authorization
- Idempotency
- Optimistic concurrency where appropriate
- Atomic state mutation
- Transactional outbox
- Reliable event publication
- Compensation / reconciliation
Optimizes for scalable reads:
- Read models / replicas
- Tenant-scoped cache-aside
- Distributed mutex where cache-stampede protection is justified
- Explicit staleness policy
Uses durable publication and consumer-side idempotency instead of assuming exactly-once network delivery.
Tracks failure scope and executes bounded compensating actions rather than globally rolling back unrelated work.
The E2A calibration principle remains:
Financial-integrity controls belong at the business logic layer when domain complexity justifies them.
Three questions help choose the correct control layer:
- Input mutability — can amounts or quantities legitimately change during the process?
- Output ambiguity — can the same apparent value represent different business meaning?
- Audit exposure — what is the consequence of an incorrect posting?
Higher ambiguity and exposure justify stronger domain controls such as sagas, explicit idempotency, reconciliation, and ledger invariants.
Lower-risk flows may be adequately protected through simpler platform-level deduplication and infrastructure controls.
→ Decision reference: reference/calibration-principle.md
E2A treats RAG as a controlled subsystem rather than merely a vector-search operation.
A complete knowledge lifecycle considers:
- Source authority and classification
- Chunk lineage
- Tenant-scoped indexing
- Retrieval authorization
- Metadata and freshness
- Grounded generation
- Evaluation
- Release, fallback, or escalation
The architecture should preserve enough evidence to determine what knowledge influenced an answer or action.
Tools are enterprise integration boundaries.
Material tool paths should consider:
- Input schema validation
- Identity and authorization
- Tenant context
- Endpoint/tool allowlisting
- Credential isolation
- Timeout and retry policy
- Circuit breaking
- Idempotency where relevant
- Structured result contracts
- Physical-outcome confirmation
- Trace and audit evidence
MCP can standardize tool discovery and invocation. It does not replace these enterprise controls.
E2A distinguishes failure classes instead of applying retries indiscriminately.
| Failure class | Representative treatment |
|---|---|
| Invalid input | Fail fast |
| Policy violation | Fail closed |
| Transient model/tool failure | Bounded retry with backoff |
| Repeated dependency failure | Circuit break |
| Low-quality model output | Repair, fallback, or escalation |
| Retrieval insufficiency | Clarify, fallback, or human review |
| Partial physical effect | Compensate or reconcile |
| Poison asynchronous work | DLQ + operational investigation |
| Cost-budget violation | Stop, downgrade, or route |
Failure handling should preserve causal evidence and remain policy-driven.
Agentic production systems require conventional telemetry plus AI-native evidence.
- Request / workflow latency
- Tool latency and success
- Retry / circuit-breaker activity
- Queue depth
- Error rate
- Availability
- Groundedness / faithfulness
- Relevance
- Structured-output validity
- Policy compliance
- Task success
- Input/output tokens
- Model selection
- Cost per request/workflow
- Cache hit rate
- Loop / delegation count
- Completed business outcome
- Escalation / exception rate
- Human approval or override
- Adoption and workflow completion
Exact targets should be derived from the use case rather than copied mechanically between systems.
E2A separates stable architecture contracts from provider-specific realizations.
| Capability | Google Cloud | Microsoft Azure | AWS |
|---|---|---|---|
| Compute | Cloud Run / GKE | Container Apps / AKS | ECS / EKS / Lambda |
| Foundation models | Vertex AI | Azure AI Foundry / Azure OpenAI | Amazon Bedrock |
| Vector retrieval | Vertex AI Vector Search | Azure AI Search | OpenSearch Service |
| Relational state | AlloyDB / Cloud SQL | Azure Database for PostgreSQL | Aurora / RDS |
| Messaging | Pub/Sub | Service Bus / Event Grid | SQS / SNS / EventBridge |
| Cache | Memorystore | Azure Managed Redis | ElastiCache |
| Secrets | Secret Manager | Key Vault | Secrets Manager |
| Observability | Cloud Operations | Azure Monitor / Application Insights | CloudWatch / X-Ray |
| Durable workflow | Workflows | Durable Functions / Logic Apps | Step Functions |
These are reference mappings, not claims of semantic equivalence between provider services.
Agent implementations that depend exclusively on supported E2A contracts can remain largely unchanged across provider adapters. Deployment configuration, infrastructure, provider capabilities, and adapter implementations can still differ.
The project history includes discovery-oriented architectural spikes as well as later/evolved reference runtimes that exercise formalized framework patterns.
| Project | Stack | Patterns explored |
|---|---|---|
| Financial Settlement Platform | Java / Spring Boot / Kafka / Redis / PostgreSQL | Saga, idempotency, financial-integrity, distributed messaging |
| Order-to-Cash Agentic AI | Python / LangGraph / Bedrock / OpenSearch / Terraform | Multi-agent orchestration, RAG, policy controls, NFR-first delivery |
| Payment Reconciliation Engine | Python / FastAPI / Lambda / SQS / DynamoDB / Bedrock | Serverless idempotency, asynchronous processing, DLQ, agent routing |
Evidence discipline: These projects are architecture R&D and reference implementations. They demonstrate architectural feasibility and implementation patterns; they should not be described as production validation unless a specific repository provides explicit evidence of that status.
Repository documentation uses the following vocabulary deliberately:
| Classification | Meaning |
|---|---|
| Framework invariant | Architectural rule E2A intends to enforce |
| Implemented capability | Present in concrete code |
| Architectural spike | Experiment used to discover or challenge a hypothesis |
| Reference runtime | Implementation used to exercise formal framework patterns |
| Recommended production pattern | Guidance requiring contextual validation |
| Directional design | Extension or hypothesis under architectural exploration |
This keeps architectural intent, implementation evidence, and future direction separate.
E2A is intentionally not the answer to every AI problem.
Before introducing framework machinery, ask:
- Does the use case actually require probabilistic reasoning?
- Does the workflow interact with enterprise data, tools, or systems of record?
- Is the action material, regulated, or difficult to reverse?
- Will multiple domains reuse the same controls?
- Can a managed cloud capability satisfy the requirement directly?
If those answers do not justify additional infrastructure or abstractions, prefer the simpler system.
- 📄 E2A Framework document
reference/mapping-tables.md— cross-runtime architectural mappingreference/nfr-first-sequence.md— NFR-first engineering sequencereference/calibration-principle.md— financial-integrity calibration
ONE GOVERNED ENTRY POINT
|
v
VALIDATE IDENTITY + STATE + POLICY
|
v
PROPAGATE EXPLICIT EXECUTION CONTEXT
|
v
REASON / RETRIEVE / PLAN
|
v
EVALUATE BEFORE TRUST
|
v
AUTHORIZE TOOL OR COMMAND
|
v
EXECUTE THROUGH CONTROLLED ADAPTER
|
v
CONFIRM PHYSICAL OUTCOME
|
v
TRACE + AUDIT + MEASURE BUSINESS RESULT
Same enterprise principles. Different runtime. Explicit boundaries. Measurable outcomes.
Subham Gupta
Architecture R&D focused on enterprise distributed systems, cloud-native modernization, governed Agentic AI, developer platforms, and production-oriented AI engineering.
All trademarks, service marks, and logos referenced in architecture examples are the property of their respective owners. References to SAP, AWS, Google Cloud, Microsoft Azure, Meta, LangGraph, and other technologies are for educational and architectural purposes and do not imply endorsement.