Introduction
Contract generation looks simple from the outside: upload a CPQ document, select a template, and generate a contract. In practice, it becomes a distributed systems problem once real business rules, template logic, approvals, review workflows, audit requirements, and model safety controls are introduced.
CPQ (Configure, Price, Quote) documents contain structured attribute and pricing data that drives contract customization. In this platform, the CPQ PDF is parsed into structured JSON, mapped against a contract template, and used to determine which clauses, sections, placeholders, and pricing-related fields should be modified, retained, or removed.
This system is not a single LLM call with tools attached to it. It is a microservice-based agentic platform running on Oracle Kubernetes Engine, or OKE. The frontend, API gateway, queue workers, LangGraph workflow services, agent services, MCP servers, tool pods, registry service, storage layer, cache layer, database, guardrails, and observability components are separated so that each responsibility can be deployed, scaled, monitored, and recovered independently.
The main design goal is to keep contract automation fast without turning it into a black box. Business users get a simple generate-and-review experience, while the backend preserves traceability, structured execution, retry control, role-based access, auditability, and tool-level isolation.
At a high level, the platform accepts CPQ and contract template inputs, stores large files in OCI Object Storage, sends processing requests through OCI Queue, validates uploaded content through guardrails, coordinates multi-step execution using LangGraph, selects agents through a registry, invokes approved tools through MCP servers, persists workflow state in Redis or OCI Cache, and stores final contract and review results in the database.
The architecture diagram below should be read as a microservice decomposition rather than a user journey. Each box represents an independently deployable or independently scalable responsibility in the contract generation and review platform.
What This Is Not
This is not a demo where an LLM writes an entire contract from scratch. The model is not treated as the source of truth for legal language, pricing, or business policy.
The system works with governed inputs: CPQ JSON, contract template JSON, admin-defined business rules, tool outputs, schemas, and persisted workflow state. The LLM reasoning step is used to help apply structured rules and select the next controlled action, not to invent the contract independently.
This is also not one large backend service that parses files, calls models, executes tools, updates the database, and handles retries in the same runtime. The platform is intentionally decomposed into smaller services so that document parsing, workflow orchestration, agent planning, MCP invocation, contract processing, review comparison, evaluation, audit, and retry handling can evolve independently.
Why an Agentic Microservice Architecture
Contract generation is not a single-step activity. A typical request can involve document parsing, template extraction, CPQ-to-template mapping, clause augmentation, rule-based changes, validation, persistence, and final document generation.
The same is true for contract review. Once a user modifies a generated contract, the system needs to compare the revised version with the original contract and identify what changed.
A traditional workflow could hardcode each step in a fixed sequence. That works when documents are predictable and business rules rarely change. This use case needed something more flexible and more operable at production scale.
The solution needed to answer questions such as:
- Which agent should handle this request?
- Which tools should that agent be allowed to call?
- Can a tool be scaled without scaling the entire workflow?
- Can failed requests be retried safely?
- Can long-running document operations resume asynchronously?
- Can administrators change business rules and tool access without changing the entire application?
- Can generated output be compared with ground truth for evaluation?
- Can every step be traced for debugging, audit, and governance?
That is where the combination of OKE, OCI Queue, Object Storage, LangGraph, Agent Registry, A2A, MCP servers, isolated tool pods, guardrails, evaluation workflows, async handling and retry/DLQ handling becomes valuable.
The architecture is agentic, but the core design principle is microservice decomposition. Agents are only one part of the system. The stronger design choice is that planning, execution, tool access, storage, workflow state, validation, review, observability, and governance are separated into explicit service boundaries.
Why OCI Queue and Object Storage Instead of Direct API Calls
The platform avoids long-running synchronous API calls for contract generation and review. Contract parsing, template extraction, agent execution, tool invocation, LLM reasoning, document generation, and comparison can all take longer than a normal request-response cycle should handle safely.
The FastAPI Gateway therefore performs only the entry-point responsibilities: request validation, metadata creation, file upload coordination, and queue message publishing. Large files are stored in OCI Object Storage, while queue messages carry request IDs, object paths, user context, workflow type, and correlation metadata.
OCI Queue decouples user-facing APIs from backend processing. The frontend does not wait for CPQ parsing, contract augmentation, or review comparison to complete inside the original HTTP request. Instead, dedicated queue workers consume messages and start the correct backend workflow.
This design gives the platform several operational advantages:
- API services remain lightweight and responsive.
- Workers can scale independently based on queue depth.
- Failed messages can be retried without forcing the user to resubmit files.
- Dead Letter Queues isolate requests that exceed retry limits.
- File payloads do not move through the queue layer.
- Generation and review pipelines can use separate queues, workers, and retry policies.
OKE provides the Kubernetes runtime for these services. The frontend, FastAPI Gateway, queue workers, LangGraph workflow services, agent services, MCP servers, and individual tool pods can all run as separate workloads with their own scaling, health checks, resource limits, and observability.
OCI Object Storage is used as the durable document layer for uploaded CPQ PDFs, contract templates, generated artifacts, and review inputs. The database stores request metadata, workflow status, structured outputs, review results, and audit-relevant records. Redis or OCI Cache stores resumable workflow state, including request IDs, current graph state, pending async steps, retry counters, and callback correlation data.
The important design choice is that the API gateway does not become the processing engine. It hands off work to queues, object storage, workers, and workflow services so the rest of the platform can operate asynchronously and recoverably.
Architecture: Microservice Decomposition on OKE
The architecture has two primary backend flows: contract generation and contract review.
In the generation flow, the system accepts a CPQ PDF and a contract template, stores both files in Object Storage, publishes a generation message to OCI Queue, validates the inputs through guardrails, starts the Contract Generation LangGraph workflow, invokes the required agents and MCP tools, applies business rules to structured contract JSON, persists the generated result, and updates the request status for the frontend.
In the review flow, the system accepts the modified contract and original contract, stores both files in Object Storage, publishes a review message to a separate queue, validates the inputs, starts the Contract Review LangGraph workflow, extracts both documents, compares sections, persists the differences, and returns the review result to the frontend.
Both flows use the same platform pattern, but they are not forced through the same runtime path. Generation and review can have separate queues, workers, graph definitions, agent policies, MCP servers, tools, retry rules, and scaling behavior.
The major microservices are:
- Frontend service for upload, status polling, result display, editing, download, and review screens.
- FastAPI Gateway for request validation, upload coordination, object path creation, metadata persistence, and queue publishing.
- Generation Queue and Review Queue for asynchronous request buffering.
- Queue Worker services for consuming messages and starting the correct workflow.
- Guardrails service for prompt-injection checks, malicious-content filtering, document safety validation, and PII masking.
- LangGraph workflow service for stateful orchestration, checkpointing, branching, retries, and async resume.
- Agent Registry service for active agent configuration, agent-to-tool permissions, MCP server metadata, and runtime routing rules.
- Agent services for scoped reasoning and task execution.
- MCP server services for standardized tool discovery and invocation.
- Tool pods for CPU-heavy or specialized operations such as PDF parsing, section extraction, contract processing, document comparison, and DOCX generation.
- Persistence services for request status, generated contract JSON, review output, audit metadata, and evaluation results.
- Redis or OCI Cache for resumable workflow state and callback correlation.
- Observability services for logs, traces, prompt/model inspection, operational metrics, and audit events.
This decomposition is the core of the design. The user journey may look linear, but the backend is intentionally split across independently scalable services with clear ownership boundaries.
Contract Generation Execution Path
The generation workflow is implemented as a distributed execution path across services, not as a single backend method.
The FastAPI Gateway accepts the CPQ PDF and contract template, creates a request record, uploads the files to Object Storage, and publishes a message to the Contract Generation Queue. The queue message contains metadata such as request ID, user ID, object paths, workflow type, and correlation identifiers.
A worker consumes the message and performs the first backend handoff. It loads the request metadata, retrieves the relevant object paths, calls the Guardrails service, and starts the Contract Generation LangGraph workflow only if the uploaded content passes validation.
The LangGraph workflow manages the state machine for generation. The Orchestrator Agent is responsible for planning the next action. It checks workflow state, queries the Agent Registry, identifies the next eligible agent, and hands off the action to the selected agent.
The Executor Agent is responsible for controlled execution. It invokes the selected agent, waits for a result or async callback reference, captures output, updates workflow state, and returns control to the orchestrator.
Agent execution then crosses the MCP boundary. The selected agent uses an MCP client to discover and invoke only the tools allowed by registry configuration. The MCP server routes the request to the correct tool pod, such as CPQ parsing, template extraction, section processing, or contract generation.
When a tool completes, its output is returned to the agent, then to the executor, then back into the LangGraph state. The workflow continues until the required structured outputs are available and the generated contract result can be persisted.
The final output is stored in the database as structured contract data, and the request status is updated to Completed. The frontend retrieves this status and displays the generated contract to the user.
Five Agents, Scoped Tool Access, Registry-Driven
The platform currently uses five registered agents. Each agent has a narrow responsibility and receives tool access through the Agent Registry rather than through hardcoded application logic.
1.CPQ Parsing Agent
This agent reads the uploaded CPQ PDF and converts relevant CPQ attributes, pricing tables, and key-value data into structured JSON. Its tools are focused on PDF parsing and CPQ extraction.
2.Contract Parsing Agent
This agent parses the uploaded contract template and extracts sections, clauses, placeholders, and structured template data. Its output becomes the contract template JSON used by later stages.
3.Mapping Agent
This agent maps CPQ attributes to the contract template structure. It determines which CPQ values correspond to which placeholders, sections, clauses, or contract fields.
4.Contract Augmentation Agent
This agent applies admin-defined business rules to the structured contract JSON. It uses LLM reasoning only within the boundary of CPQ JSON, template JSON, rule schema, and approved tool outputs.
5.Review Agent
This agent supports the review workflow by extracting content from the original and modified contracts, comparing sections, and producing structured review results.
The important design constraint is that agents do not receive unrestricted tool access. The Agent Registry stores which agents are active, which tools they are allowed to invoke, and which MCP server exposes those tools. At runtime, the orchestrator queries the registry before selecting an agent or allowing tool execution.
This keeps agent behavior configurable without redeploying the entire workflow. Admins can disable an agent, add a new tool, change agent-to-tool mappings, or route an agent to a different MCP server through registry configuration rather than code changes.
Registry, A2A, MCP, and Async Callbacks
The registry is the control plane for the agentic platform. It stores active agents, MCP server endpoints, available tools, tool metadata, and agent-to-tool permissions. The LangGraph orchestrator does not need hardcoded knowledge of every agent or every tool. It asks the registry what is available and then makes routing decisions based on the workflow state and the configured permissions.
A2A, or Agent-to-Agent communication, is used by orchestrator agent components and agent services via the registry. The orchestrator sends structured instructions to the selected agent, and the agent returns structured results, status, errors, or callback metadata. This keeps agent execution observable and traceable across the workflow.
MCP, or Model Context Protocol, is used between agents and tools. MCP gives agents a standardized discovery interface. FastMCP’s custom route is used for invocation so that we can handle the async callback logic. This avoids point-to-point coupling between agent containers and tool pods. Instead of embedding tool clients directly inside every agent, agents connect to MCP servers that expose approved tools in a consistent way.
This separation gives the platform three useful boundaries:
- The registry controls what exists and what is allowed.
- A2A controls how orchestration components communicate with agents.
- MCP controls how agents discover and invoke tools.
The async callback pattern is used when an agent, MCP server, or tool cannot complete work within a short synchronous execution window. In those cases, the workflow persists state, pauses execution, and resumes later when a webhook callback returns with the job ID or correlation ID. This prevents long-running document operations from blocking service threads or depending on fragile HTTP timeouts.
MCP Servers and Tool-Level Scaling
The MCP server layer separates agent reasoning from tool execution. Agents decide what action is needed, but the actual document operations run behind MCP servers and tool pods.
The Contract Generation MCP Server exposes tools such as:
- parse_pdf_tool
- extract_sections_tool
- process_contract_tool
The Contract Review MCP Server exposes tools such as:
- extract_contract
- compare_sections
Each tool can run in its own Kubernetes Pod. That matters because these operations do not have the same resource profile. CPQ PDF parsing may be CPU-heavy. Contract extraction may require different memory limits. Section comparison may spike during review-heavy periods. DOCX generation may have a different scaling pattern from LLM-assisted augmentation.
By isolating tools into separate pods, the platform can scale the expensive pieces without scaling the entire agent stack. It also allows each tool to have its own health checks, logs, resource requests, limits, deployment version, and rollback strategy.
This is the microservices advantage inside the agentic architecture. The system does not treat agent tool use as an in-process function call. It treats tool execution as a distributed service boundary with explicit routing, permissions, observability, and scaling behavior.
Applying Business Rules with LLM Reasoning
One of the most important parts of the solution is how contract template JSON is modified.
The system does not simply ask an LLM to write a contract. That would be too open-ended for an enterprise workflow.
Instead, the platform works with structured inputs:
- CPQ JSON extracted from the CPQ PDF.
- Contract template JSON extracted from the Word template.
- Admin-defined business rules.
- A rule schema that tells the LLM how each rule should be interpreted.
The LLM reasoning step uses these inputs to modify the contract template JSON based on CPQ attributes and admin rules.
For example, an admin rule may say that when a certain CPQ attribute has a specific value, a related clause or section in the template should be updated, removed, retained, or replaced. The LLM helps apply that rule to the structured contract JSON.
This gives the business team more flexibility. Rules can evolve without rewriting the entire workflow. At the same time, the model is grounded in a schema and structured data, rather than being asked to generate content with no boundaries.
That distinction is important. The LLM is not replacing governance. It is helping apply governed business logic.
Completing the Contract Generation Flow
After all required agents and tools have completed their work, the final generated contract data is stored in the database.
The database status is updated to Completed.
The frontend can then display the generated contract in the UI.
At this point, the user can review the generated contract, make changes, add or remove clauses, update section data, and prepare the final version.
When the user clicks Download Contract, the frontend calls another FastAPI Gateway endpoint. The gateway uses XML-to-DOCX conversion logic to convert the contract content into a Word document.
This gives users a familiar final output: a downloadable contract file that can be shared, reviewed, stored, or sent through downstream business processes.
Contract Review Execution Path
The review workflow reuses the same platform pattern but has its own queue, workflow, agent path, MCP tools, and output schema.
The user uploads two documents: the modified contract and the original contract. The FastAPI Gateway stores both files in Object Storage, creates or updates the review request record, and publishes a message to the Contract Review Queue.
A review worker consumes the message and sends the uploaded documents through the Guardrails service. Once validation passes, the worker starts the Contract Review LangGraph workflow.
The review workflow state tracks the request ID, original contract path, modified contract path, extracted original sections, extracted modified sections, comparison output, retry metadata, and final review status.
The orchestrator selects the Review Agent based on the workflow state and registry configuration. The Review Agent does not compare documents inside the agent container itself. It calls the Contract Review MCP Server, which exposes the approved extraction and comparison tools.
The extract_contract tool converts each contract into structured section data. The compare_sections tool then identifies added, removed, or modified sections and produces a structured difference result.
The review result is stored in the database and associated with the original request. The frontend displays the comparison output so that users can understand what changed after the generated contract was modified.
The key design point is that review is not a separate monolith. It is another workflow running on the same agentic microservice platform, with separate scaling and governance boundaries.
Retry, Recovery, and DLQ Handling
Production systems fail in small ways all the time. A tool may time out. A pod may restart. A model call may fail. A document may have formatting issues. A queue worker may crash in the middle of a request.
The architecture handles this through retry rules at two levels:
- Agent-level retries.
- LangGraph workflow-level retries.
Redis or OCI Cache stores the LangGraph state so that retry logic can use the latest workflow context. LangGraph supports state persistence through checkpoints, which helps workflows continue with remembered state instead of starting from scratch every time.
After three retry attempts, the queue message is moved to the Dead Letter Queue.
This is an important operational pattern. A DLQ should not be treated as a failure graveyard. It is a place where the team can inspect problematic requests, understand why they failed, fix the underlying issue, and reprocess when appropriate.
This helps avoid silent failures. A document that cannot be processed does not disappear. It becomes visible and traceable.
Webhook-Based Async Resume with Redis and LangGraph Interrupts
Long-running enterprise workflows require asynchronous orchestration patterns to remain reliable at scale. The platform uses webhook-based asynchronous execution to prevent HTTP timeout issues during contract generation and review operations.
Certain stages in the workflow, such as document parsing, contract processing, comparison, or multi-agent execution, can take significantly longer than a standard synchronous HTTP request lifecycle. Instead of keeping the connection open while processing continues, the platform pauses the workflow and resumes it later through asynchronous callbacks.
This async execution pattern is implemented across multiple layers of the architecture, including the MCP server layer, the agent layer, and the LangGraph workflow layer. At the MCP server level, long-running tool executions can return control immediately and send the final response later through a webhook callback once processing is complete. At the agent level, agents can wait for dependent tool responses without blocking the entire workflow execution. At the LangGraph level, workflows can pause safely using LangGraph interrupts and resume execution once the expected callback or external response is received.
Whenever the workflow reaches a step that depends on an asynchronous response, the current execution context is persisted in Redis before the workflow is paused. Redis stores the request ID, workflow state, pending execution step, retry count, and correlation metadata required to resume the same workflow later from the exact interruption point.
Once the external process, MCP server, tool, or agent completes its operation, it sends a webhook callback back to the platform. The callback contains the request ID or correlation ID, allowing the backend services to identify the correct paused workflow. The backend then retrieves the saved workflow state from Redis and resumes the LangGraph execution from the interrupted step instead of restarting the entire process from the beginning.
Redis also plays an important role in retry management and workflow recovery. If a webhook callback fails, a tool response is incomplete, or a resumable workflow step cannot continue successfully, the retry metadata in Redis is updated accordingly. Using the persisted workflow state, the platform can retry only the failed step while preserving the remaining execution context. Once the configured retry threshold is exceeded, the request can be marked as failed and routed to failure handling workflows or Dead Letter Queue processing.
This architecture significantly improves resiliency for enterprise-scale document workflows. LangGraph interrupts enable workflows to pause cleanly, webhook callbacks allow MCP servers, agents, and workflow services to return results asynchronously, and Redis provides the persistent workflow state required to resume, retry, recover, or fail requests in a controlled and traceable manner.
Observability and Audit
The platform uses OCI Logging to capture application details across the contract generation and review pipelines.
Logs can include request IDs, workflow steps, agent execution details, tool invocation status, errors, retries, callback events, queue message state, and completion events.
Audit is also implemented to capture important activity in the project. This is especially relevant because contracts are sensitive business documents. Teams need to know who submitted a request, what flow was triggered, what status changed, and where important actions occurred.
The architecture also includes Langfuse for prompt and model observability. This is useful when administrators experiment with prompts and models, compare outputs, and troubleshoot behavior across agentic workflows.
Good observability is not just a developer feature. In an enterprise contract system, it is part of trust.
The system needs to answer operational questions such as:
- Which request failed?
- Which workflow step failed?
- Which agent was running?
- Which tool was invoked?
- Was the failure caused by parsing, model output, callback timeout, validation, or persistence?
- Was the request retried?
- Did it reach the DLQ?
- What output was generated before failure?
These questions are easier to answer because the architecture uses explicit service boundaries and persists workflow state.
Role-Based Access Control
Role-based access control is part of the agentic platform.
This matters because not every user should be able to do the same thing.
A business user may generate and download contracts.
A reviewer may compare modified contracts.
An admin may configure rules, manage registry settings, assign tool access to agents, and evaluate model behavior.
RBAC keeps these responsibilities separated.
It also supports the registry-driven design. Admin users can decide which agents are active and which tools each agent can access. This prevents the system from becoming an uncontrolled set of agents with unrestricted tool access.
In agentic systems, permissions matter as much as prompts.
Guardrails and PII Masking for Uploaded Documents
The Guardrails Logic layer sits before the LangGraph workflows. This is the right place for it.
The system checks the CPQ PDF and contract Word file before agent reasoning begins. That reduces the chance that malicious instructions hidden inside uploaded content influence the workflow.
The platform also implements PII masking before sending CPQ or contract content to the LLM. Sensitive business information and confidential data are identified and masked to reduce unnecessary exposure during prompt processing. This helps ensure that only the required contextual information is shared with the model while protecting enterprise-sensitive content.
A contract document might contain normal business language, but it could also contain text that looks like instructions to the model. Guardrails help separate document content from system instructions.
This workflow proceeds only after the guardrails check passes.
This design keeps safety close to the entry point of the pipeline, before agents, tools, and model reasoning become involved.
Evaluation framework: Measuring What Matters Before Production
The platform includes an Evaluation framework for authorized users—a practical environment for testing how the contract-generation system behaves before a change reaches production.
In the current application, the framework is centered on CPQ extraction. Users can upload one or more CPQ PDFs, select an active evaluation model, associate each file with a ground-truth JSON record, and run evaluations in parallel. A single fallback ground truth can be selected for ad hoc uploads, while folder-based runs require an exact filename match. This prevents accidental comparisons against the wrong expected result.
The purpose is simple: turn subjective feedback—“the output looks right”—into measurable evidence. For every evaluated document, the framework compares the extracted JSON against the expected JSON, identifies missing, extra, and mismatched fields, and presents both the complete payloads and a differences-only view. It also summarizes attribute counts, matched fields, mismatches, and values missing from the parsed result.
Evaluation goes beyond structural JSON comparison. The framework also validates CPQ business logic against the ground truth. It reports individual rule checks as pass, fail, missing, or optional, explains why a check failed, and calculates an overall score based on applicable checks. This makes it possible to distinguish a harmless formatting variation from a meaningful issue in contract inputs, pricing data, or downstream rule application.
The framework is designed to make experimentation controlled and traceable. Users can select from registered evaluation models and manage prompt versions for the two core CPQ extraction stages: attribute extraction and table extraction. A prompt can be edited and used for the current evaluation session without immediately changing the production default. Each result retains the model, prompt identifiers, token usage, estimated cost, parsed output, ground truth, differences, and business-logic result. Saved results can later be reopened, allowing teams to revisit a prior run rather than relying on screenshots or memory.
Why evaluation is essential
Evaluation is particularly important whenever the system changes—even when the change appears operational rather than functional.
A deprecated model is one common trigger. Model providers retire models, change availability, or introduce newer versions with different capabilities. Replacing a model may improve quality, but it can also alter extraction behavior in subtle ways: a field may be omitted, a table may be interpreted differently, or a value may be normalized in an unexpected format. Running a representative ground-truth set before migration provides evidence that the replacement is safe.
Prompt changes require the same discipline. A small instruction change can improve one document type while causing regressions in another. By evaluating the same CPQ files with the current and proposed prompt versions, teams can see precisely which attributes or business-rule checks improved, changed, or failed. This supports prompt iteration without treating production traffic as an experiment.
Latency and cost improvements should also be evaluated, not merely benchmarked. A faster or less expensive model is valuable only if the quality remains acceptable. The framework records token usage and estimated cost alongside extraction and rule-validation outcomes, helping teams evaluate the real trade-off: quality, speed, and cost together.
The same process applies to parser updates, schema changes, new CPQ formats, revised business rules, and infrastructure changes. Evaluation provides a regression safety net before deployment and a diagnostic tool afterward. When a production issue occurs, a saved result can help reproduce the behavior against a known input and expected output.
In an agentic contract platform, evaluation is therefore not a separate quality-assurance activity. It is part of the production control loop. The system that extracts contract data and applies rules must also provide a disciplined way to measure accuracy, understand failures, compare models and prompts, and make changes with confidence.
Why This Architecture Works Well on OKE
OKE is a good fit for this platform because the agentic system is naturally made of multiple services.
The frontend can scale separately from the gateway.
Queue workers can scale based on message volume.
LangGraph workflow services can scale based on active requests.
MCP servers can be deployed independently.
Individual tools can scale based on their workload.
This is especially useful for document-heavy workloads. PDF parsing, contract extraction, and comparison do not always have the same resource needs. A microservice approach avoids forcing every part of the system to scale together.
OKE also supports a clean separation between platform concerns and business logic.
The platform handles deployment, scaling, service isolation, networking, and container orchestration.
The business layer handles CPQ parsing, template mapping, contract generation, rule application, and review.
That separation keeps the system easier to operate as it grows.
Deploying the Architecture on OCI Enterprise AI
The same containerized architecture can also be deployed on OCI Enterprise AI as managed hosted applications. Each application component can be packaged as a container image, stored in OCI Container Registry, and deployed through OCI Enterprise AI Applications and Deployments. OCI manages the application runtime, scaling, networking, storage integration, authentication, and application endpoints, while the platform retains its existing service boundaries and business logic. Oracle: Hosted Applications and Deployments
OCI Enterprise AI also provides managed model inference through hosted foundation models, imported models, and dedicated model deployments. This allows the same deployed applications to call managed inference for CPQ extraction, template mapping, contract generation, document review, and agent-driven business-rule evaluation. The architecture therefore combines managed application hosting with managed AI inference in one enterprise platform. Oracle: Enterprise AI Models
Service Boundaries in a Single Request
A single generation request crosses several service boundaries. Those boundaries are intentional because each one gives the platform a control point.
The API boundary validates the request, creates metadata, uploads files, and publishes the queue message.
The queue boundary decouples user-facing latency from document-processing latency.
The worker boundary separates message consumption from workflow orchestration.
The guardrails boundary prevents uploaded document content from being treated as trusted model instructions.
The LangGraph boundary manages durable workflow state, branching, retries, and resumable execution.
The registry boundary controls which agents exist, which tools are available, and which agent is allowed to invoke which tool.
The A2A boundary standardizes how orchestrators and agents exchange tasks, results, errors, and callback metadata.
The MCP boundary standardizes how agents discover and invoke tools.
The tool-pod boundary isolates expensive or specialized document operations into independently scalable workloads.
The persistence boundary records request status, structured outputs, generated contract data, review results, evaluation artifacts, and audit-relevant metadata.
This boundary-driven design is what makes the platform production-oriented. The system can observe, retry, scale, replace, or secure individual parts of the flow without turning the whole contract platform into one tightly coupled service.
Security and Governance Considerations
Contract workflows often involve confidential business terms, pricing details, customer information, and legal language. Any enterprise implementation should review privacy, security, retention, access control, and compliance requirements before connecting tools, models, MCP servers, or external systems.
This architecture includes several governance controls:
- Uploaded files are stored in OCI Object Storage.
- Queue messages pass file paths and metadata instead of large document payloads.
- Guardrails check document content before workflow execution.
- PII masking reduces unnecessary exposure during prompt processing.
- PII data encryption protects sensitive stored information.
- RBAC separates user and admin responsibilities.
- Agent access is controlled through registries.
- Tool access is assigned by administrators.
- MCP servers expose only approved tools.
- Tool pods isolate specialized execution from agent containers.
- OCI Logging captures operational details.
- Audit tracks important events.
- Retry and DLQ handling make failures visible.
- Admin evaluation compares generated output against ground truth.
These controls help make the agentic system suitable for enterprise contract workflows, where speed is important but control is non-negotiable.
Conclusion
The important architectural pattern is not simply that the platform uses agents. The stronger pattern is that agentic behavior is placed inside a governed microservice system.
Queues control asynchronous execution. Object Storage keeps large files out of the message path. LangGraph manages durable workflow state. The registry controls agent and tool access. MCP standardizes tool invocation. Tool pods isolate workload-specific execution. Guardrails and PII masking protect the model boundary. RBAC, audit, logging, evaluation, retries, and DLQs make the system operable in an enterprise environment.
This design also leaves room for future evolution. New contract types can be added as new workflows. New tools can be introduced behind MCP servers. Business rules can evolve without rebuilding the full platform. Review logic can become more sophisticated without changing the generation path. Evaluation data can be used to compare prompts, models, rule changes, and extraction quality before production rollout.
The open challenge is not whether agents can generate useful contract outputs. The harder problem is whether those agents can be constrained, observed, recovered, evaluated, and governed as part of a production system. That is where this architecture puts most of its effort.