Series II: From infrastructure to agentic projects in production. Episode 20 of 20.
A portal can have modern infrastructure, programming and monitoring agents, yet still lose a request between two services. For an SME, architecture becomes useful when it explains the outcome, the responsible party and proof of each step. The main decision: validate a complete flow before expanding autonomy or the number of components.
We conclude the series with the fictional B2B portal for requests and documents. We are focusing on a single feature: the partner uploads a document, receives an identifier, and an agent prepares a summary for operator review. This is a proposed technical scenario, with no client, measured results or claimed savings.
A contract for the outcome, before technology
A flow end-to-end, meaning from start to result, includes the behavior observed by the user, not just the model call. A request is considered accepted only after it has been durably saved. The summary must be linked to the correct document and version; the operator reviews it before a commercial decision.
We set boundaries from the start: the agent does not approve contracts, does not delete documents and does not automatically send external communications. If the summary cannot be produced, the request remains visible and can be processed manually. An AI outage should not hide the client’s request.
Saltzer, Reed and Clark explained the end-to-end result verification principle in their 1984 academic paper. For the portal, the proposed application is simple: confirming message delivery does not prove that the summary was saved and reviewed.
Two types of agents, two paths
The development agent works on code: it receives a defined task, follows repository rules and proposes changes. The team’s shared memory stores architectural decisions and test evidence, not uncontrolled copies of partner documents. Coordination prevents overwrites and assigns integration to a designated person.
The agent integrated into the portal is a component of the production application. It receives a separate identity and access only to the documents needed for the current task. The development agent’s access to code does not grant access to real production data. These boundaries link the episodes about project, tools, memory and identities.
From requirement to installable version
The requirement includes anonymized examples, summary fields and checks for access between organizations. We evaluate the change using these cases, including rejections and incomplete documents, not just based on a single convincing response.
The CI/CD flow—continuous integration and delivery—builds an artifact, the installable application package. We tie the code version, tests, dependency inventory and build provenance to this package. SLSA 1.2 describes provenance as verifiable information about the origin of an artifact’s production. Using such evidence does not automatically certify application security or the correctness of AI responses.
We propose testing the package in pre-production, then human approval and installation of the same package. Environment configuration and secrets remain separate. Reproducible environments and segmented networks support the flow regardless of on-prem, cloud or hybrid setup. We do not assume the portal needs Kubernetes or separate services for every function.
Minimal portal map
A reference architecture is an explained proposal, adaptable to the project, not a configuration already validated. The diagram distinguishes software delivery from document processing. The drawn components are logical responsibilities; some may run within the same application. The API is the communication interface between components and the outbox is the registry of events to be dispatched.
The documents are stored in a private repository. The database records the request, document version, processing status and result. Only the authorized application can access them. OWASP recommends checking permissions on every object accessed through the API. A hard-to-guess identifier does not replace permission checks.
From upload to summary
After validating the uploaded document, the application saves the request and processing event in the same database transaction. The transaction allows both writes to be confirmed together or rolled back together. We do not assume it automatically includes external file storage.
A separate process reads the outbox and sends the job to the processing queue. The transactional outbox pattern, documented by AWS, addresses the inconsistency between writing to the database and sending a notification. However, messages can still appear repeatedly; the consumer must handle duplicates.
A worker background process checks access, reads the authorized version and invokes the model. It validates the result structure and saves it with the job identifier. Reprocessing the same job must not create duplicate final results. The interface displays the status, and the operator checks the summary against the document.
The agent's memory, the context sent to the model and any caches or reused information, all respect organizational boundaries. The optimizations described in the previous episode are only accepted after measuring latency, resource usage and quality along this route. Public content for search remains separate from private documents.
A simulated error to validate the system
We simulate stopping the worker after saving the summary and before confirming the message. On redelivery, the system recognizes the already completed job and retains a single result. We verify this property in the application; a queue marked as reliable does not prove it on its own.
Next, we simulate model unavailability. The request keeps an explicit state, with limited retries and the option for manual processing. The operational owner decides on intervention. Operational responsibility means tracking operation, responding to incidents and applying the recovery procedure if needed.
We correlate events using the request identifier and a trace the path of execution through components. OpenTelemetry provides instrumentation for signals such as logs, metrics and traces. These help diagnosis but do not automatically prove summary correctness. We avoid full documents and secrets in telemetry and check sensitive data filtering.
The recovery test uses backup copies restored in an isolated environment and checks the link between requests, files and results. Rolling the application back to a previous version does not automatically undo database changes. The procedure must be tested with the real data state.
Responsibility sheet and acceptance
This is the proposed responsibility sheet for the monitored functionality:
Responsible | Decision or action | Required evidence |
|---|---|---|
Product owner | Accepts the behavior and autonomy limits | Approved acceptance cases |
Development team | Integrates and verifies the change | Code, tests and identified artifact |
Infrastructure administrator | Controls environments, access and recovery | Configuration and restoration tested |
Operational owner | Monitors alerts and leads intervention | Log and procedure verified |
Business operator | Checks summary before decision | Result linked to the correct document |
The same person can have multiple roles in an SME, but responsibilities and a substitute must be established. The agent does not become the approver of their own release.
We accept the whole set when the normal workflow, repetition, access denial and recovery have verifiable evidence. This connects the twenty episodes: a manageable architecture where each component serves a result, every boundary is tested and each intervention has an assigned responsible person.
Sources
Sources verified on 20 October 2026. The portal, diagram, tests and responsibility sheet are technical proposals, not the results of an implementation or certification.
- SLSA 1.2: approved specification
- SLSA 1.2: artifact provenance
- AWS: transactional outbox, duplicates and write consistency
- OWASP API Security 2023: object-level authorization
- OpenTelemetry: observability concepts
- OpenTelemetry: handling sensitive data
- Saltzer, Reed and Clark: End-to-End Arguments in System Design, ACM TOCS, November 1984
Connect the pieces into a coherent architecture
Would you like us to connect these pieces into a project suited to your company? Talk to i8 about architecture, development and operations.
