Skip to content
Intura
enid
Enterprise Small AI Models: Custom Training and Integration / Integration
Integrate

Our models, running inside your stack and your agent workflows.

A model you downloaded is a directory on disk. Getting it to answer inside the service, the agent or the workflow that needs it, on machines you already run, at a latency and memory cost you can afford, is integration work, and it is what this service does. We install the models with the intura_ai Python SDK, wire them into your applications, agents and workflow tools, measure them on your hardware, and hand the result to the team that will run it.

The problem

The problem it solves

Most teams that try a small model stall in the same place: it works in a notebook, and nobody has the time to turn it into a step in production. The open questions are practical. Where does it run, how is it loaded and kept warm, what happens when a call fails, how does a new version replace the old one, and is it fast enough on the hardware you have? Until they are answered, every message keeps going to a large hosted model, paid for per token, for a job a CPU could do. We answer them in your environment, so the small model actually takes the job over.

Who it is for

Who it is for

  • Engineering teams building AI agents that need a fast tool for one decision on every turn

  • Teams putting guardrails in front of an LLM: prompt-injection screening and PII masking before a prompt leaves the building

  • Operations teams on workflow tools such as n8n who want a classification or extraction step without a per-call bill

  • Companies whose data cannot leave their VPC, their premises or the device

What we do

What we do

  1. 1

    Map the decisions

    We walk through the flow with your team and mark where a small model replaces or protects a call: the message to classify, the prompt to screen, the field to extract, the conversation to route.

  2. 2

    Choose and test the models

    We pick from the catalogue, or scope a custom model where nothing fits, and try the candidates on a sample of your own data before anything is wired in.

  3. 3

    Wire them in

    We install the models with the intura_ai Python SDK and connect them where they are needed: a service behind your API, a tool your agent calls, a step in a workflow, a guard in front of your LLM. Failure paths and fallbacks are designed, not left to the defaults.

  4. 4

    Benchmark on your hardware

    We measure latency, throughput and memory on the CPUs, edge devices or instances you will actually run, and size the deployment from those measurements rather than from ours.

  5. 5

    Hand over

    Your team gets the code, the configuration, a runbook for deploying, updating and rolling back, and a walkthrough with the engineers who will own it.

What you get

What you take delivery of

  • The integration code, in your repository
  • Models installed through the intura_ai SDK, pinned to the version you tested
  • A benchmark report from your own hardware
  • A runbook: deploy, move to a new model version, roll back, monitor
  • A handover session for the team that will operate it

How it runs

How an engagement runs

A typical integration moves through four phases. Its length depends mostly on how many places a model has to be wired into and how much access to your environment we can be given, so the proposal after the first call states the timeline for your case rather than this page guessing at it.

  1. 01

    First call

    An engineer, not a salesperson. We hear what the flow does today and where it hurts.

  2. 02

    Scoping

    A short written proposal: which decisions, which models, which environment, what you provide and what you receive.

  3. 03

    Build and benchmark

    Work happens in your environment or a copy of it, with a review at each step.

  4. 04

    Handover

    Code, runbook and walkthrough. Support afterwards is optional and agreed separately.

FAQ

Common questions

Do we get the models separately?

You get catalogue models from each model's own page, and they stay in your library with every version, the same as for anyone else. If the job needs a model the catalogue does not have, that part becomes a custom model and is scoped together with the integration.

Does anything we process leave our network?

No. The models run on your machines and make no network call when they answer. The SDK downloads model files with your download key; after that, inference is local.

Will it work with our agent framework or workflow tool?

Usually. A model is a Python call, so anything that can call Python, run a container or reach an internal HTTP service can use it. Tell us what you run on the first call and we will say plainly if there is a gap.

What if our hardware turns out to be too slow?

That is what the benchmark is for. We measure before handover, and if the numbers do not fit we say so and propose the change, such as a smaller model, batching or a different place to run it, rather than shipping something that cannot keep up.

Read the SDK docs first

How download keys, loading a model, predicting and versions work in the intura_ai Python SDK.

Open the docs

The other Enterprise services

Enquire

Tell us what you need

Describe the problem, the team and where it has to run. An engineer reads every enquiry and replies by email.

You will get an engineer on the first call, not a qualification script.