An agent prepares a supplier-contract review. It retrieves applicable documents, extracts dates and obligations, compares the material and submits a synthesis to a responsible person. The workflow may combine document retrieval with checks and a mechanism for coordinating the work.
These components solve different problems. The following four decisions describe information, checks, dependencies and permitted actions. They form a proposed design framework, not terminology shared by every vendor.
1. Retrieve the information supporting the answer
Retrieval-augmented generation, or RAG, finds passages and sends them to the model with the question. In the contract example, these may include an annex or an approved internal rule. The answer depends on the collection’s state and the available permissions.
Preparation preserves document structure and metadata, including version and effective date. An annex detached from its contract can lead to a wrong answer even if its text was parsed correctly. The index must retain the relationships needed for interpretation.
Keyword search can find an exact reference. Vector search can match related meanings. Hybrid retrieval combines signals before ranking results. The team evaluates the options on real questions, including names and amounts that distinguish similar records.
A knowledge graph explicitly represents relationships between entities, such as suppliers, contracts and signatories. GraphRAG approaches use such structures to support retrieval; Microsoft’s documentation describes one implementation.
The graph requires extraction and maintenance. It earns that cost when explicit relationships improve the selected questions. Hybrid search with metadata may be sufficient elsewhere. The comparison concerns relevance and coverage, together with operating effort.
Permissions apply before documents reach the model. Authority to review one contract does not grant access to every confidential supplier file. Tests must include questions that cannot be answered by revealing material outside the user’s scope.
2. Verify the result before continuing
The model may produce prose or structured fields such as an expiry date and its source clause. A schema makes automatic validation easier; it does not prove the extracted date is correct.
Checks compare the result against identified evidence. A calculation must match its inputs. A quotation must exist in the stated version. A termination date must include relevant conditions from the contract. Missing information should remain visible rather than be filled by assumption.
A loop may ask for correction after a failed check. Useful feedback identifies the fault, such as a missing reference. Application code sets limits on attempts and spending, including the time available.
A second model can help review the answer, but agreement is not necessarily independent verification. Both models may use the same obsolete source. Deterministic checks and human review can provide different evidence.
3. Coordinate tasks and preserve their state
An execution graph describes tasks and dependencies. A knowledge graph describes relationships in the data. Both can exist in the same system without performing the same function.
Retrieving annexes and extracting contact details may proceed independently. A synthesis of obligations must wait for the documents it needs. Parallel work helps when tasks are independent and resources are available; it does not automatically improve reasoning quality.
Each step receives defined input and produces an identifiable result. The next step consumes that result with its state and errors. Free prose may suit a human reader. An operation that changes a system generally benefits from structured, validated data.
Durable execution is useful when work must survive a restart or wait for approval. A dossier may wait for several days. The system retains the version reviewed, pending request and authorised decision-maker.
Conditions can change during that wait. A replaced contract or revoked permission may invalidate a proposal. The engine checks relevant conditions before resuming rather than treating every earlier approval as permanent.
Operations also need safe retry behaviour. Repeating a step must not create another dossier or send a duplicate message. Idempotence, where repetition preserves the intended effect, requires suitable identifiers and controls in the called tools.
4. Authorise actions according to consequences
Read, preparation and execution permissions address different risks. A draft synthesis does not commit the organisation in the same way as sending a contractual notification.
The procedure identifies permitted actions and those needing approval. The reviewer receives the sources and uncertainties and can amend or reject the proposed action. The time and information available must make that review practical.
Controls remain in the application and authorisation systems. Instructions to the model do not replace technical access restrictions. A received document cannot grant itself a new tool or wider account permissions.
The harness is the software that runs the agent loop, calls its tools and applies permissions. It preserves step state, prepares the context passed to the model and records operations in logs. Execution stops when it reaches the configured timeout, cost limit or retry count.
Evaluate a complete dossier
The first trial uses known cases, including incomplete or contradictory material. The team examines retrieved documents and extracted information, then the detected errors and actions actually possible. Duration and accepted-result cost belong in the same assessment.
| Decision | Acceptance question |
|---|---|
| Retrieval | Does the result use the right versions and permissions? |
| Verification | Does the system detect errors and missing information? |
| Orchestration | Can work resume without losing state or duplicating an action? |
| Authorisation | Does each action respect its permissions and approvals? |
A component is justified when a test shows the problem it solves. A loop should improve a measurable result; a graph should organise useful dependencies; durable state should enable correct recovery. This reasoning keeps the architecture understandable as the application grows.
Continue with four agent workflows and their acceptance criteria.