Contents
An LLM integration needs a clear contract between the model and the application. Identify the information it receives, the result it should produce and what the application will do with that result. Choose the pattern from the task and its boundaries rather than starting with a framework or a chat interface.
Use direct generation for a bounded output
For a drafting or summarisation feature, define the input material and the intended output. Decide whether the result is a suggestion for a person or content that another process will consume. Make the review responsibility visible in the user journey.
Keep the task sufficiently explicit to evaluate. Ask what information must be preserved, what should be omitted and what an unacceptable result looks like. Handle a missing or unusable response as an incomplete task rather than displaying it as a successful result.
Validate structured results before using them
If the model extracts fields or proposes a classification, define a schema and the permitted values. Validate the response before passing it into domain logic. A correctly shaped response still needs semantic checks: a date can be syntactically valid but inappropriate for the record being processed.
Decide how ambiguity is represented. Avoid forcing a value when the source does not provide enough evidence. Give uncertain cases a review path and keep the original material available to the authorised reviewer where appropriate. Specify what happens when a validation check fails.
Use retrieval when the task depends on selected information
Microsoft describes retrieval-augmented generation as combining search with an LLM so a response can use retrieved data. The integration therefore needs attention to the information selected as well as the generated answer. Retrieval is a way to supply context, not a guarantee that the result is correct.
Identify the source of truth, how updates reach the retrieval system and which records the requesting user may access. Test questions whose answers are missing, outdated or split across sources. Where the interface provides citations, check that they support the associated statement and point to material the user can appropriately inspect.
Expose tools as constrained application operations
For a tool-enabled feature, define the allowed operations and validate their arguments. Enforce authorisation in the application each time data is read or changed. The model's request to use a tool is a proposal for an operation, not proof that the user has permission to perform it.
Separate read operations from mutations and define the review needed for consequential actions. Make retryable writes resistant to duplication. Use the tool's actual result to determine success, and retain an understandable status when an external system rejects the action.
Keep orchestration understandable
If the task uses several stages, specify what each stage receives and returns. Decide which transitions are fixed rules and which are model-directed choices. Keep intermediate validation and stopping conditions explicit so the team can explain why the application took an action.
Set limits appropriate to the task and operating budget. Record safe diagnostic information that distinguishes a provider failure from invalid input or an application error. Avoid collecting raw user content in ordinary telemetry when an identifier and a coarse failure category are sufficient.
Evaluate the integration, not just the response
Build representative cases for the complete journey, including boundary violations and unavailable dependencies. Check the input selection, output handling and downstream effect together. Compare changes to the model, prompt, retrieval configuration or tools against the same relevant cases.
Document the pattern chosen and the reasons alternatives were not needed. Keep a route for disabling or revising the feature if it fails its operating criteria. An integration is maintainable when the receiving team understands both the model's role and the responsibilities that remain in application code.
Match four integration patterns to four outputs
For a fictional service desk, direct generation suits a draft summary of text the user already supplied. Structured extraction suits proposed fields such as request type and date, provided the application rejects invalid or unsupported values. Retrieval suits a policy answer that must use current authorised documents. A tool operation suits looking up an accepted request state through a constrained application interface.
Compare the failure boundary for each. A summary can omit a material exception; extraction can invent a valid-looking date; retrieval can return an obsolete or inaccessible policy; a tool can be asked to fetch another organisation’s request. Test those cases separately. A valid JSON shape is not proof that the underlying information is true, and a citation is useful only when it supports the associated statement.
Keep writes as explicit business operations. A generated suggestion to close a request does not close it; the application validates the state and user authority, obtains any required approval and confirms the accepted result. Microsoft’s retrieval guidance explains how retrieved context enters generation. That pattern supplies information; it does not replace permission enforcement, source freshness or output verification.
How this relates to Veda Software’s work
Powerleague illustrates the distinction between a user-facing action and a fulfilment handoff. It supplies no LLM integration evidence. The patterns here concern software engineering, with strategy and adoption retained by VEDA AI.