How we build
Technologies
The approaches we combine to connect AI with your knowledge, software, and workflows.
Each approach solves a different part of the problem. We select and combine them around the work your team needs to do.
01 / Instructions
Prompt engineering
Give the model a clear brief.
What it is
Prompt engineering shapes the instructions an AI model receives for a task. Those instructions can define its role, describe the desired outcome, provide examples, and specify a response format. A well-designed prompt gives the model a usable brief each time the application calls it. The underlying model stays the same; the application changes what it asks the model to do.
Why use it
This is often a practical starting point when a capable model already understands the task, but needs clearer direction. It supports repeatable activities such as extracting information, summarizing documents, drafting content, and classifying requests. Instructions can also express business preferences, including terminology, writing style, and when to flag uncertainty for review.
How it is implemented
We define what a successful result looks like, build reusable prompt templates, and test them against representative examples and difficult cases. The application supplies the current input and checks the returned structure. Prompts are versioned and evaluated as requirements or models change. Additional retrieval or software connections can be added when the task requires information beyond the supplied material.
Instructions guide the model without changing its weights.
Illustrative output
- Issue
- Conveyor stopped.
- Next action
- Inspect the sensor using the approved procedure.
The requested format determines the fields. Add an example to demonstrate more specific wording.
Read the diagram
- Task. Define the work the model should do and provide the current input.
- Example. An example demonstrates the terminology and response style you want.
- Output format. Specify the fields and structure the application expects.
- AI model. The model receives the task, supplied examples, and output requirements.
- Response. The application checks the response against the requested format.
Where it helps
- Manufacturing
- Shift summaries
- Enterprise software
- Support triage
- Retail
- Product descriptions
More applications
A manufacturer could turn technician notes into consistent shift summaries. An enterprise software team could categorize support requests and draft release notes. A retailer could turn approved product specifications into catalog descriptions. A logistics business could extract shipment details from incoming messages, while a professional services team could prepare structured meeting summaries. Each application benefits from explicit requirements about required fields, acceptable language, and the details a person should verify.
See an output example
An illustrative shift summary
Issue: Conveyor stopped at station 4. Observation: Packaging material obstructed the sensor. Next action: Follow the approved inspection and restart procedure.
A reusable instruction asks for the same three fields in every summary.
Illustrative example using fictional data.02 / Knowledge
RAG and context engineering
Bring your knowledge into the conversation.
What it is
Context engineering determines which information a model receives when it works. That can include instructions, documents, conversation history, application state, and tool results. Retrieval-augmented generation, or RAG, is one way to supply that context: the application searches relevant knowledge sources and includes selected passages alongside the user's question. The model uses this material to produce a response, often with references that readers can inspect.
Why use it
This approach helps when answers depend on private, specialized, or changing information. It makes company knowledge useful inside an application without requiring that information to be learned through model training. Sometimes supplying a particular record directly is sufficient. Retrieval becomes useful when the relevant material must be found across a larger collection.
How it is implemented
We connect approved sources, prepare searchable content, and retrieve relevant material with access controls applied. Search may combine keywords and semantic similarity. The application assembles a focused context, requests a grounded response, and evaluates both retrieval and answer quality. Freshness, source references, and behavior when evidence is missing are part of the design.
Retrieved material enters the context. The model’s weights remain unchanged.
Read the diagram
- Question. The user supplies a question that guides retrieval.
- Documents. Approved documents provide source material, with access controls applied.
- Records. Relevant records can be retrieved or supplied directly.
- Selected context. Retrieve useful passages and assemble them with the question.
- AI model. The model receives the question and selected supporting material.
- Cited answer. The response includes references to the supporting source material.
Where it helps
- Manufacturing
- Maintenance guidance
- Enterprise software
- Internal knowledge
- Retail
- Product and policy questions
More applications
Manufacturers could search maintenance manuals and service histories. Enterprise teams could answer product questions or prepare proposals using approved company knowledge. Retail staff could compare products against current specifications and return policies. Construction teams could locate project requirements across drawings and specifications. A hospitality operator could help employees find location-specific procedures. Across these examples, the answer is more useful when people can see which source supports it and check that source's relevance.
Follow a source
An illustrative policy answer
Answer: Unused items may be returned within 30 days, according to the store’s return policy [1].
[1] Sample return policy: “Unused items in their original packaging may be returned within 30 days of purchase.”
Illustrative example using fictional data.03 / Software connections
Tool and function calling
Let AI work with your software.
What it is
Tool calling connects an AI model to functions exposed by an application. A function might look up a stock level, calculate a price, retrieve an account, or create a service request. The model produces a structured request identifying the tool and its inputs. Application code checks that request, performs the permitted operation, and returns the result so the model can continue or explain what happened.
Why use it
This approach is useful when the job requires current system information, precise calculations, or an action in existing software. It allows people to express a need in everyday language while established business systems remain responsible for the underlying records and transactions.
How it is implemented
We define focused tools with clear descriptions and input schemas, connect them to APIs, and enforce authentication, permissions, and validation in application code. Actions can require human approval. The integration also handles errors, retries, duplicate requests, and audit records. A successful model response must accurately reflect whether the underlying operation succeeded.
The tool result returns to the model before it prepares a response.
Read the diagram
- AI model. The model requests an operation using a named tool and structured inputs.
- Application checks. Application code validates inputs, permissions, and any required approval.
- Business API. The connected system performs the permitted operation.
- Tool result. The actual result returns to the model, which can then prepare a response.
Where it helps
- Manufacturing
- Spare-part availability
- Enterprise software
- CRM updates
- Retail
- Order lookups
More applications
A manufacturer could check spare-part availability and prepare a maintenance ticket. A retailer could look up an order or request an approved stock reservation. Enterprise software could let employees retrieve account details and update an authorized CRM field. A distributor could calculate a quote using its pricing engine. A property manager could create a work order from a tenant's description. In each example, the interface translates intent into a controlled operation, and shows the user the result or the next required decision.
Inspect a tool request
An illustrative inventory lookup
Request: Check availability for part A104. Application check: The user has inventory read access. Tool result: Two units available. Response: Part A104 has two units available.
A reservation would be a separate write operation with its own permission and approval checks.
Illustrative example using fictional data.04 / Coordinated workflows
Agentic AI and orchestration
Coordinate the steps needed to reach a goal.
What it is
Orchestration coordinates model calls, software tools, data, and checks across a process. Some workflows follow a predefined sequence. An agentic system gives a model more responsibility for choosing the next step based on its goal and what it observes. It can gather information, use a tool, inspect the result, and continue until it finishes, reaches a limit, or needs a person to help.
Why use it
This approach fits work that spans several systems or requires adaptation as new information appears. A single response may be insufficient when the task involves research, preparation, execution, and verification. The amount of autonomy should follow the variability of the task and the consequences of a mistake.
How it is implemented
We define the goal, available tools, workflow state, completion criteria, and escalation points. The application manages progress, permissions, time and cost limits, and recovery when a step fails. Some steps use ordinary code; others benefit from a model's judgment. Multiple specialist agents are an option when they add value, but one model working through a controlled loop can be sufficient.
The observed result informs the next step, completion, or human handoff.
Read the diagram
- Goal + inputs. Define the goal, available information, and completion criteria.
- Workflow + state. The orchestrator tracks progress, observations, permissions, and limits.
- AI model. The model proposes the next step using the current workflow state.
- Checked action. The application validates the step and performs a permitted operation.
- Observed result. Inspect what happened and update the workflow before choosing another step.
- Finish or hand off. Complete the work when criteria are met, or route it to a person when needed.
Where it helps
- Manufacturing
- Maintenance work packages
- Enterprise software
- Request qualification
- Retail
- Order exception handling
More applications
A manufacturer could investigate a maintenance exception, gather service history, and prepare a work package for approval. An enterprise team could qualify an incoming request, assemble supporting information, and route it to the right owner. A retailer could investigate a delayed order and propose an appropriate resolution. Logistics teams could coordinate disruption research and revised delivery options. Service businesses could assemble project handover packs while tracking missing inputs and unresolved decisions.
Show a workflow exception
An illustrative service workflow
The preferred replacement part is unavailable. The workflow checks approved alternatives, gathers availability, and prepares a proposal for a person to review.
The workflow stops at the approval step. It does not place an order in this illustration.
Illustrative example using fictional data.05 / Model adaptation
Fine-tuning and training
Adapt the model to a specialized task.
What it is
Fine-tuning adapts a pretrained model using task-specific examples. Training updates model parameters, or an attached adapter, so the model learns patterns that influence later responses. This can shape classification, terminology, output structure, or other repeatable behavior. Broader training can include continued pretraining on a domain corpus or building a model from scratch, which involves a substantially different data and infrastructure commitment.
Why use it
Fine-tuning is worth considering when a stable task needs more consistent behavior than the existing prompt and context approach achieves, and suitable training data is available. It can also support a smaller specialized model. Any benefit in quality, latency, or operating cost needs to be demonstrated against a baseline.
How it is implemented
We define measurable targets, prepare representative examples, and separate training data from validation and test sets. We train or adapt a suitable model, compare it with the baseline, and check for regressions before deployment. The adapted model still receives instructions and can use retrieval or tools. Changing business facts usually belong in maintained sources or connected systems.
Training and evaluation happen before release. New requests use the adapted model.
Read the diagram
- Training examples. Prepare representative task examples and separate evaluation data.
- Base model. Start with a suitable pretrained model.
- Training. Update model parameters or an adapter using the training examples.
- Evaluation. Compare against a baseline on held-out data and check for regressions.
- Adapted model. Release the model or adapter only after it passes evaluation.
- New input. Supply a new task input and instructions when the model is used.
- Adapted model. Use the evaluated model or adapter for this request.
- Task response. Check the response for the application’s requirements.
Where it helps
- Manufacturing
- Defect classification
- Enterprise software
- Document extraction
- Retail
- Catalog normalization
More applications
A manufacturer could categorize recurring defect descriptions using its own taxonomy. Enterprise software could extract fields from a consistent family of documents. A retailer could normalize supplier descriptions into a common product catalog. A logistics company could classify shipment exceptions. A service organization could standardize the structure of operational reports. These are candidates for evaluation when there are enough trustworthy examples of the desired behavior and a clear way to judge unseen inputs.
Compare task behavior
An illustrative classification
Input: “Mounting bracket with surface pitting.” General category: Component issue. Target taxonomy: Surface finish / Pitting.
Training examples can teach a chosen taxonomy. Evaluation on unseen inputs determines whether the adaptation improves the task.
Illustrative example using fictional data.Choosing an approach
The approaches
work together.
The right combination starts with the work.
Consider a service assistant investigating a machine issue. A prompt defines the task. Retrieval supplies the relevant manual and service history. Tools check parts availability. Orchestration coordinates the investigation and prepares a work package for approval.
A specialized model can support the same workflow when adaptation is justified. We evaluate model choices against the task, while building around your information, systems, and business requirements.
Find the right approach
for your workflow.
Tell us what your team is trying to achieve, where the relevant information lives, and which systems are involved.
Discuss your project