Skip to content
Salvador
Advisory Group

AI engineering, for production

If you can’t measure it, you’re still prototyping.

We define the evaluation harness, engineer the AI agents and the tooling around them, and hand over a system running in your environment, wherever that is.

Book a 15-minute callSee how we work

The system we build

One request through a production agent, end to end.

Vendor-agnostic by design. The same shape holds on any cloud and with any model provider, and every arrow in it is something we build, test and hand over.

Reference architecture

Reference architecture for a production AI agentA request travels from your users through an identity-aware gateway into an agent runtime in your tenant. The agent acts with the caller’s identity, calls models through one model gateway, writes to systems of record and commits state with a receipt, and every step is traced and scored against a frozen evaluation set that gates the next release.YOUR USERSEDGEAGENT RUNTIME · YOUR TENANTMODEL GATEWAYMODELSSYSTEMS OF RECORDSTATEIDENTITYOBSERVABILITYTool calls · idempotentOrchestrator + agentsPolicy + guardrailsAPI · streamingYour peopleweb, chat, or your own appGatewaySSO · WAF · rate limitsReasoning modelsfrontier and smallEmbeddingsfor retrievalAny providerswap without a rewriteIdentity provideron-behalf-of tokensTraces and costevery step, per taskEval harnessfrozen set gates releaseState + receiptscommits onceKnowledgeindexed for retrieval12345678

Full system overview

01 Your gateway

The request comes in through your gateway, signed in with your own SSO.

What we do

We engineer AI agents into the systems your company runs on.

The agent works inside the systems your business already depends on. It acts as the person who asked, through your identity provider, and leaves an audit trail your security team can read.

  • 01

    Identity and permissions

    The agent acts as the person who asked, with their scope, rather than as one service principal holding read access to everything. That is most of the distance between a pilot and something a security review will pass.

    • Entra ID
    • Microsoft Graph
    • Delegated access
    • Audit trail
  • 02

    Safe tool calls

    The moment an agent writes to a real system, retries stop being a detail. Idempotent operations, atomic boundaries, and create-only receipts, so a tool call never executes twice when it times out.

    • Idempotent retries
    • Atomic boundaries
    • Optimistic concurrency
  • 03

    Evaluation harness

    An eval set agreed before the build, frozen, and re-run on every release. Until the behaviour is scored against something that has stopped moving, better is an opinion rather than a number.

    • Frozen eval set
    • Stated baseline
    • Release gate
  • 04

    Traces and cost

    Every tool call and hand-off lands on a trace the on-call rotation can read at 2am, and cost is measured per task rather than per token, because the retries, the tool calls, and the validation passes are where the invoice comes from.

    • Distributed traces
    • Cost per task
    • Ceilings per workflow
  • 05

    The smallest thing that works

    Rule, classifier, retrieval, model, agent. Autonomy, cost and failure surface all climb with every step down that list, so we reach the last one only when the ones above it genuinely cannot do the job.

    • Rule
    • Classifier
    • Retrieval
    • Model
    • Agent
  • 06

    The systems already there

    The important systems are old and are not being replaced first. We work against the APIs, batch jobs, and constraints that actually exist, in your tenant and your repo, with your engineers on the PRs.

    • Brownfield APIs
    • Your tenant
    • Your repo
    • Your pipeline

What we hear

Six places this goes wrong, over and over.

Almost none of them are model problems. They live between the working notebook and the system your security team, your finance team, and your on-call rotation can all live with.

“We want an agent here.” Underneath that sentence sit four unresolved questions: which system holds the truth, who makes the call today, what success means to the business owner, and whether that matches what the engineering lead thinks is being built. A bad scope is an architectural defect that lands before the architecture exists.

We’ve been deploying past all six.

How we work

We take on three shapes of work.

Which one you need is usually clear within fifteen minutes of talking, and we’ll say so on the call rather than in a proposal two weeks later.

  • Build

    You have a prototype and a review date.

    We start by building the evaluation harness, because until the behavior is measurable there is nothing to optimize against. Then we harden the integration with your APIs and identity provider, make the tool calls safe to retry, wire up the traces, and ship it on infrastructure your SOC will sign off on. The code lives in your repo from the first commit.

    Includes

    • Frozen eval set
    • Production agents
    • Identity & API integration
    • Idempotent tool calls
    • Traces and observability
    • SOC-ready deploy

  • Scale

    The first one shipped and three more are queued behind it.

    We codify what worked so the next ones take a week each instead of a quarter: the eval harness, the deployment pattern, the guardrails, the cost ceiling per task. Telemetry from the live system feeds new cases back into the eval set, so the standard rises with each release instead of drifting.

    Includes

    • Reusable eval harness
    • Multi-agent topology
    • Governance
    • Cost ceilings per task
    • Roadmap

  • Teach

    Your team owns it before we leave.

    From day one your engineers pair with ours and read every PR. We teach the parts that are hard to hire for right now: how to turn a fuzzy business behavior into a loss function, how to read a trace, and how to decide when the honest answer is a rule instead of a model. When we go you have the code, the runbook, and the people who wrote it.

    Includes

    • Pair-engineering
    • Code review
    • Eval design
    • Runbooks
    • Architecture decisions
    • Clean handoff

Why us

We’ve done this enough times to have opinions.

We’ve shipped agent systems inside Fortune 500 environments where security review takes longer than implementation, and “production” means SSO, audit logs, and a real on-call rotation. Most of our time goes into the parts nobody demos: identity, retries, traces and the eval set.

  • Senior engineers, no pyramid

    The people on your Slack channel are the people writing the code, so a technical question gets a technical answer on the spot, from someone who has read the diff.

  • Microsoft ecosystem fluency

    Entra ID, Microsoft Graph, Microsoft 365, Cosmos DB and Purview are what an agent needs to act as the user, govern data and pass review. They are where most of our working hours go.

  • We’ll tell you where AI agents don’t belong

    A rule is cheaper and safer than a model when the problem is deterministic, and a small classifier is enough when routing is all you need. Now that almost anything is buildable, the useful answer is often yes, but not there, and not like that.

Questions

What people ask before the first call.

The same questions come from CTOs, security teams and engineering leads. Here are the answers we give them.

Something else? , our AI assistant.

Do you only work on Azure?

We are strongest in the Microsoft stack: Azure, Entra ID, Microsoft Graph, Microsoft 365 and Purview, which is where most enterprise identity and data already live. The architecture itself is not tied to one vendor, and the models behind the gateway can come from whichever provider fits the task.

Where does the code live when you leave?

In your repo, deployed through your pipeline, running in your tenant. It has been there from the first week, so there is no migration at the end and no dependency on us after it.

What happens to our data?

It stays in your environment. The agent runs in your tenant, acts with the permissions of the person who asked, and every tool call lands on a trace your security team can read.

How long does an engagement take?

Evaluate takes one to two weeks and ends with a scorecard and a prioritized plan. Prove takes four to eight weeks and ends with an agent in production, measured against an eval set agreed at the start. Operate is ongoing and optional. You can stop after any phase.

How do you price the work?

Phase by phase. Each phase is scoped before it starts, so you know what you are buying, what it costs and what you keep, and you see the results of one phase before deciding on the next.

Who actually does the work?

Senior engineers. The people on your calls and in your Slack channel are the people writing the code, and your engineers pair with them from the first week.

What if an AI agent is the wrong answer?

Then we will say so. A rule is cheaper and safer when the problem is deterministic, and a small classifier is enough when routing is all you need. You will hear it on the first call.

Can you train our team as well?

Yes. Pairing is part of every engagement, and the Academy runs a private two-day program for enterprises: day one for every employee, day two for the engineers who put it into production.

The first call

Fifteen minutes, three questions.

If we’re a fit, we’ll tell you. If we’re not, we’ll point you somewhere that is.

Book a 15-minute call

Quick question instead? , our AI assistant.

  1. What are you trying to put in production?

  2. What would prove it works, and who gets to decide?

  3. Who runs it once it’s live, and what comes after the first one?