Building an AI assistant, agent or platform: what your project needs

You want employees to find answers in company documents. Or a support agent that can look up an order, prepare a reply and update the right record. Perhaps your team spends too much time turning PDFs, emails and public information into a dossier someone can review.

Each request describes a system worth scoping. It also brings different engineering work: connecting sources, managing access, choosing how models are used, integrating actions and keeping the service running.

This is why a project needs AI architecture expertise. Someone must turn the business request into a coherent system and connect the work of the people building it. That responsibility may sit with an internal architect or a delivery partner. Its value becomes clearer when you look at what you actually want to build.

You want an assistant that answers from company knowledge

Imagine a project manager asking: “What did we agree with this client, and which document confirms it?” The answer needs the relevant agreement, its current version and the manager’s right to see it.

A common approach is retrieval-augmented generation, or RAG: the application finds relevant material and gives it to a language model as context for its answer. Building it involves both the search process and the preparation of the underlying documents. Microsoft’s RAG design guide explains those two parts.

For this project, the scope should include:

• Source connections: which document stores and business tools supply information, and which source takes precedence when records disagree.
• Document processing and search: extracting useful content, making it searchable, and handling revisions and deletions.
• Access control: restricting retrieval to material the person asking is authorised to see.
• Answer design: showing supporting sources and making missing or conflicting information visible.
• Evaluation: testing representative questions, changed documents and access restrictions before widening use.

The expertise combines data engineering, search, application development and security. A useful acceptance example is specific: after an agreement changes, the assistant should retrieve the new version, cite it and respect the same access restrictions as the source system. Our guide to evaluating company knowledge assistants develops these checks.

You want an agent that works across your business tools

Consider a support request about a delayed order. You want the system to identify the customer, check the order, consult the delivery policy and prepare the next step in your CRM or support platform.

This introduces actions and their consequences. The project needs a clear account of what the system may read, propose and change.

• Process design: define the trigger, expected outcome and exceptions that require a person.
• Tool integrations: provide controlled access to the CRM, ERP or support system through their APIs.
• Action permissions: decide which changes may run automatically and which require approval, with limits enforced by the application.
• Execution state and retries: record completed and pending work, handle uncertain results, and design retries to avoid applying the same change twice.
• Operational controls: set limits on steps, time and spend, with a way to stop execution and investigate failures.

One architectural choice is how much of the sequence the model should decide. A predefined workflow can handle a known sequence; an agent can choose its next step within the permissions you give it. Anthropic’s distinction between workflows and agents is useful here.

For the delayed order, the first scope might end with an evidence-backed reply ready for approval. Sending it or changing an order adds requirements. Our agent architecture framework shows how tools, permissions and execution records fit together.

You want to turn documents into a usable dossier

Your team may need to review supplier submissions, prepare responses to tenders or assemble information about a prospective customer. The work starts with mixed material and ends with something structured enough for a person to use.

Scope the output first. For a supplier dossier, that could mean a company profile, extracted specifications, a comparison against your requirements and a list of unresolved questions.

The system then needs:

• Intake and extraction: accept the relevant formats, read text and tables, and use optical character recognition where needed.
• A consistent structure: put each finding in the right field while retaining its document or source reference.
• Reconciliation: surface missing values, contradictions and uncertain interpretations for review.
• Defined processing steps: decide where code, a language model or a specialist extraction tool performs each task.
• A review interface: let someone inspect evidence, correct findings and decide what happens next.

Different models may help with different tasks. That choice should follow evaluation on your documents. A second model is justified when it solves a demonstrated problem in the workflow; it also adds a component to test and operate.

The practical test is whether a reviewer can use the dossier and trace its important findings without repeating the entire collection exercise.

You want a shared AI platform for several teams

Suppose sales needs a knowledge assistant, operations needs document processing and support needs an agent connected to its tools. Some foundations may be worth sharing: access to models, identity, connectors, evaluation tools and usage reporting.

A platform project adds responsibilities beyond any one application:

• Common services: decide which capabilities are reusable and which belong to a particular workflow.
• Separation: keep team, client and project data within their authorised boundaries.
• Capacity and cost controls: manage demand, usage limits and attribution of operating costs.
• Release management: test changes to shared components against the applications that depend on them.
• Ownership: define who operates the platform, who supports each application and how incidents are handled.

This brings platform engineering, infrastructure, security and AI application architecture into the same scope. The Azure AI architecture guidance shows how applications, data and models sit in separate layers.

Build the shared layer around concrete recurring needs. If only one workflow is understood, define and test that workflow before committing to a broad internal platform.

If private cloud is a requirement, make the boundary explicit

Any of these systems may come with a requirement to keep certain data or processing within a controlled environment. Establish exactly what that means before choosing the infrastructure.

A private cloud is infrastructure dedicated to one organisation; it can be operated on or off its premises. That is the NIST definition. The project still needs to specify where each component runs and where information travels.

Include document storage, text extraction, the generation of search representations (embeddings), search indexes, model and tool calls, logs and backups in that map. Hosting the application internally does not establish that an external model service receives no data.

If the models must also run within your environment, the scope extends to serving them: compute capacity, memory, simultaneous requests, updates and recovery. The operating team and budget need to cover that work. Ask for a deployment design tied to the actual data restrictions and expected workload.

What the architect and delivery team should put in your hands

An architect connects these decisions and identifies the specialists the project needs. Delivery may involve backend and data engineers, product designers, infrastructure engineers and security specialists, depending on the scope.

Translate that expertise into concrete outputs when commissioning the work:

Keeping a language-model application working as its sources, prompts and models change is part of LLMOps. It includes evaluation, deployment, monitoring and feedback throughout the application’s life. Microsoft’s LLMOps overview describes this lifecycle.

Agree the first useful scope and its acceptance criteria before expanding. Our guide to choosing a first AI project shows how to fix that scope, its price and a pass/fail test. An internal assistant and an agent authorised to change customer records can share components while requiring different levels of review and operational support.

How IZZY approaches this work

At IZZY, we specialise in building AI applications and agents connected to business workflows. Our AI Agents & LLM Products service covers applications, retrieval, integrations, evaluation and monitoring.

We use models where the work requires interpretation, extraction or synthesis. Explicit business rules stay in code or workflow logic. Records and statuses persist between steps, and exceptions have a defined route to review. This is the approach described in our published operational projects.

A concrete example: preparing startup dossiers

In an IZZY startup pre-screening project, a new CRM record starts public-source collection. When a pitch deck arrives, its contents are extracted and organised into a predefined structure. Models perform complementary tasks. The system answers predefined questions with yes, no or possible where supported, and flags missing information. The resulting classification supports further human review. Investment decisions remain with people.

The published case brings together CRM integration, document processing, model orchestration and evidence handling. It illustrates the engineering behind a specific business request: prepare a dossier that someone can assess.