AI engineering

AI engineering on Azure AI Foundry

Most organizations have now run an AI pilot. Far fewer have anything in production. The gap is rarely the model. It is permissions, grounding, evaluation, cost control, and someone owning the thing after launch. That gap is what we build.

What “in production” means here

An agent we deliver is deployed in your Azure tenant, on private networking, behind your identity provider, with authentication that respects the permissions the user already has. It has an evaluation set, a cost ceiling, logging, and a named owner on your side. If it only runs on a laptop or in a demo tenant, it is not done, and we do not call it done.

What we build

Retrieval over your own data. Grounding on SharePoint, Microsoft Fabric, SQL, Dataverse or line-of-business APIs, with the retrieval layer respecting document-level permissions, so the agent cannot surface to one employee what another employee was not allowed to open.

Agents that take action. Not just answering. Filing the ticket, drafting the record, triggering the workflow, with the boundary of what the agent may do written explicitly and enforced, not implied by a prompt.

Evaluation before deployment. We build a test set from your real cases at the start, and measure against it on every change. That is what makes the difference between “it seemed good in the demo” and a system you can defend in a review.

Guardrails and observability. Content filtering, prompt and response logging, rate limits, and a dashboard your team reads rather than a log nobody opens.

Cost model. Token consumption forecast per use case, budget alerts, and the honest answer about which model tier the workload actually needs. Most workloads do not need the largest model, and paying for it is a silent recurring cost.

How an agent actually runs on Azure Six stages, in order, each one a resource in your own subscription. There is no third-party orchestration host anywhere in this picture, which is the difference between a workflow tool and a deployed system. The evaluation stage is the one most pilots skip, and skipping it is why they cannot be defended in a review.
  1. Trigger
    The agent is called, or an event calls it. Either way the caller is authenticated before anything else happens.
    • Front door API Management Publishes the endpoint, applies the rate limit, and keeps the agent off the public internet unaltered.
    • Events Event Grid The batch path: a document lands somewhere it was expected, and the run starts on its own.
  2. Retrieval
    The model is handed your own material, and only the part this particular user was already allowed to open.
    • Grounding Azure AI Search Vector and hybrid search with security trimming, which is the part most retrieval implementations skip and the reason they leak.
    • Extraction Document Intelligence Turns the invoice, the form or the clinical document into structured fields before a model is asked anything.
    • Source Microsoft Fabric The governed layer the index is built from, rather than forty exports that disagree with each other.
  3. Model call
    One call, on private networking, inside your tenant. Your prompts and your data do not train the model.
    • Platform Azure AI Foundry Model deployment and versioning, prompt flow, quota and the token budget that keeps the bill forecastable.
    • Model Azure OpenAI models The tier chosen against the workload. Most workloads do not need the largest model, and paying for it is a silent recurring cost.
  4. Evaluation
    Every change is measured against a test set built from your own cases, before it reaches anybody.
    • Evaluation harness Azure AI Foundry The evaluation set is the most durable thing produced here: it outlives the model it was written against.
  5. Guardrail
    What the agent may and may not do, written down and enforced, rather than implied by a prompt and hoped for.
    • Content filtering Azure AI Foundry Applied on the request and on the response, with blocked cases logged rather than quietly swallowed.
    • Classification Microsoft Purview Sensitivity labels decide what may leave the tenant and what may not, before the answer is assembled.
    • Human Named approver For any action that changes a record or spends money, a person stays accountable for the decision.
    Rejected, back to stage 3 If the evaluation or the guardrail rejects the response, the run returns to the model call with the failure recorded, or escalates to the named approver. It never passes silently, and the rejection rate is a metric on the dashboard.
  6. Output
    The result is written back where the work already happens, not into a chat window nobody rereads.
    • Action Functions Files the ticket, drafts the record, updates the line-of-business system the team already uses.
    • Delivery Service Bus Queues the action, so a downstream outage delays the work instead of losing it.

On every stage above

  • Identity Microsoft Entra ID The agent holds its own workload identity with a federated credential. Not a shared secret, and never a person’s account.
  • Observability Azure Monitor Prompt and response logging, latency and failure rates, on a dashboard your team reads rather than a log nobody opens.
  • Cost Cost Management A token cost model per use case and a budget alert set before go-live. A number you cannot forecast is a number that surprises your finance director.
  • The dark elements are where a person or a policy can stop the run, and where it goes back if they do.
  • Every box is a resource in your own subscription, deployed as code and rebuildable from it.

How the eight weeks run

Weeks 1-2: the use case, narrowed. We pick one workflow and define what “good” looks like in measurable terms. We also identify what should not be automated, which is often the more valuable output.

Weeks 3-5: build. Retrieval, orchestration, permissions, interface. Working software every week, in your tenant, not a status report.

Weeks 6-7: evaluate and harden. Measurement against the test set, failure-mode work, security review, cost model, load behavior.

Week 8: production and handover. Deployment, monitoring, documentation, and a working session with the team who owns it next.

What you keep

  • The application code and infrastructure as code, in your repository.
  • The evaluation set: arguably the most durable asset produced, because it outlives the model.
  • The cost model and monitoring configuration.
  • A written record of what the agent may and may not do, usable in a risk review.

Who this is for

Organizations with a specific, repetitive, document-heavy or decision-support workflow, and data that already exists somewhere accessible. Healthcare, industrial operations, financial services and professional services are where we see the clearest payback.

Who this is not for

If the goal is “we need an AI strategy” with no candidate workflow, start with a two-week assessment instead. An eight-week build with no target is an expensive way to discover you had a data problem. And if the data does not exist or is not governed, fix that first; no amount of prompting compensates for it.

Questions we get

How is this different from a proof of concept?

A proof of concept answers "can the model do this?" In 2026, it usually can. Production answers "does this hold up with real data, real permissions, real cost and real failure modes?" That second question is the entire engagement.

Does our data train the model?

No. Models called through Azure AI Foundry in your tenant do not train on your prompts or your data. We configure private networking so requests do not traverse the public internet, and prompt logging so you can see what was asked and answered.

What does an agent cost to run?

It depends on the model, the context size and the volume, which is why we build a token cost model during the engagement and set budget alerts before go-live. A number you cannot forecast is a number that will surprise your CFO.

What if the model gives a wrong answer?

It will, sometimes. That is why we build an evaluation set from your own cases before writing the agent, measure against it on every change, and design the interface so the human stays accountable for the decision. An agent with no evaluation harness is not finished.

Can you work with our existing data platform?

Yes. We ground agents on SharePoint, Microsoft Fabric, SQL, Dataverse and line-of-business APIs. If the data layer is the real blocker, we say so. Most failed AI projects are data projects in disguise.

Have a question about this work?

Three fields. An architect reads it and answers within one business day.

Every field is needed.

We reply to this address. Nothing else is sent to it.

The goal, the deadline, and what is in the way. Three lines is plenty.

What you send travels over TLS to our own Azure Function in Canada East and lands in our own Odoo CRM in Montreal. No third-party form script, no advertising cookie. We keep it to answer you, and delete it after twenty-four months if nothing comes of it. Privacy policy.

Bring us the workload. We bring the architecture.

Thirty minutes, one architect, no deck. Come with a problem and leave with an opinion you can act on.