Entrazure
What this engagement is
It productises the work described on the AI engineering service page and applies it to exactly one workflow. The constraint is the product. Eight weeks against one use case reaches production. Eight weeks against three reaches three demos, and the industry has enough of those.
The output is an agent deployed in your Azure tenant on Azure AI Foundry, grounded on your own data through Azure AI Search or a direct connection to the source, with retrieval that respects the permissions the person asking already holds. Around it: an evaluation set, prompt and response logging, content filtering, rate limits, a token cost model and budget alerts.
What makes a good candidate use case
Repetitive, document-heavy or decision-support, with a measurable manual baseline and data that already exists somewhere reachable. Invoice and form extraction with Document Intelligence, retrieval over a policy or contract corpus, triage and routing of inbound requests, drafting against a template with a human approving the result.
A weak candidate has no measurable baseline, depends on data nobody can locate, or is described only as a strategy rather than a workflow. If that is where you are, the two-week assessment is the cheaper way to find a candidate than discovering the absence of one in week five.
How the eight weeks run
Weeks 1 to 2, narrow the case. We define what good looks like in measurable terms and build the evaluation set from real historical cases, before any agent code is written. We also write down what should not be automated, which is often the more valuable half of the output. The choice between Azure AI Foundry and Copilot Studio is made here, on where the data lives and how much control the workflow needs, and the reason is recorded.
Weeks 3 to 5, build. Retrieval, orchestration, permissions and interface. Working software in your tenant every week, reviewable, not a status deck. Security trimming on retrieval is built in this phase and is not optional: an index that ignores source permissions is a data leak with a chat interface.
Weeks 6 to 7, evaluate and harden. Measurement against the evaluation set, failure-mode work, security review, load behavior, and the token cost model. This is where the model tier is chosen on evidence rather than on assumption, and it frequently steps down rather than up.
Week 8, production and handover. Deployment, monitoring, documentation and a working session with the team who owns it next.
What you keep
- Application code and infrastructure as code in your repository, from the first commit.
- The evaluation set, which outlives the model and is reusable for every agent after this one.
- The token cost model with visible, editable assumptions.
- Monitoring and alerting configuration.
- A written record of what the agent may and may not do, in a form a risk committee can read.
- The list of workflows we recommended against automating, with the reason.
What it costs you, in effort and access
Access: a subscription we can deploy into, ideally a governed one. Where no Azure landing zone exists, we either land in a bounded subscription and note the debt, or the four-week landing zone build runs first. Read access to the grounding data with its real permission model intact, not a flattened copy, because a demo corpus with no permissions hides the hardest part of the work.
Effort: one subject matter expert for roughly six hours a week. This is the load-bearing dependency of the engagement. The person who actually does the work today is the only one who can say whether an answer is right, and no amount of engineering substitutes for them. Plus a technical counterpart at about two hours a week, and a named owner identified by week six who will hold the agent after handover.
Effort you should also expect: two to three hours building the evaluation set with us in week one, drawn from your own historical cases. Teams that skip this end up arguing about quality with no shared definition of it.
Who this is for
Organizations with a specific repetitive workflow and data that exists. The payback is clearest in healthcare, industrial operations, financial services and professional services, where the manual baseline is measurable and the volume is real. In regulated settings, the boundary work of deciding which document may be surfaced to which role is most of the engagement rather than a formality, which is why the controls are designed alongside compliance architecture rather than added afterwards.
Who this is not for
If the goal is an AI strategy with no candidate workflow, this is an expensive way to discover you had a data problem. Start with the assessment.
If the data does not exist, is not governed, or cannot be reached without a project of its own, fix that first. No amount of prompting compensates for it, and we will not sell an agent as a way around a data platform problem.
If nobody will own the agent after week eight, do not start. An unowned production system decays faster than an unowned prototype, because people have begun to rely on it.
If residency or jurisdiction is the blocking question rather than the workflow, read Novarque sovereignty and Loi 25 first. Those constraints change the architecture, and they are cheaper to design in than to retrofit in week seven.
Questions we get
Why one use case and not three?
Because three use cases in eight weeks produces three prototypes and no production system. The first agent carries the cost of the plumbing: identity, retrieval, permissions, logging, cost control, deployment. A second use case built on that foundation runs materially faster. Doing them in parallel means paying for the foundation three times and finishing none of them.
What counts as in production at the end?
Deployed in your Azure tenant, on private networking, behind your identity provider, respecting the permissions the user already holds on the source data, with an evaluation set, logging, a budget alert and a named owner on your side. If it only runs in a demo tenant or on a laptop, it is not done and we do not call it done.
Does our data train the model?
No. Models called through Azure AI Foundry in your own tenant do not train on your prompts or your data. We configure private networking so inference requests do not traverse the public internet, and prompt and response logging so you can see what was asked and what was answered.
What if our data is a mess?
Document-heavy use cases often work on the mess as it stands, because extraction tolerates inconsistency. Anything that needs reliable numbers does not. We establish which of the two you have in weeks one and two, and if the honest answer is that this is a data platform problem, we say so then rather than in week seven.
How do you know it works?
An evaluation set of 30 to 50 real cases drawn from your own history, built before the agent is written, measured on every change. It is the most durable thing produced by the engagement because it outlives the model you started on. An agent with no evaluation harness is untested, not finished.
What does it cost to run afterwards?
That depends on model tier, context size and volume, which is why a token cost model is built during the engagement and budget alerts are set before go-live. Most workloads do not need the largest reasoning model, and we choose the tier on measured accuracy against your evaluation set rather than on the name.
Have a question about this work?
Three fields. An architect reads it and answers within one business day.