Deploys from Azure Marketplace into your own subscription.
A diagram of work moving through Eido Build inside your Azure tenant. Work
items queue in triage, then pass through design, build, code review, test
and merge. Product approves the design, Engineering approves the code and
QA signs off the tests before an item moves on, and merged items ship as
a release.
Eido is trusted by businesses around the world
We build Eido through Eido Build
Eido is our commercial Microsoft Intune product: hundreds of
customers around the world, more than 500,000 devices under
management, and 100% of it now built through Eido Build.
16×Engineering throughputFour times the work, in a quarter of the time
100%Of features and bugfixes delivered through Eido BuildEvery change to Eido now runs through it
Governance
Hundreds of engineers. Hundreds of AI policies.
Without a control plane, every engineer picks their own coding agent,
model and provider. Eido Build gives your whole organisation one
governed route to AI, inside your Azure tenant.
Without Eido Build
Every engineer is their own AI policy.
Diagram: ten engineers each connect to several different AI
services outside your network edge: a direct API key on a personal
card, a personal AI account on consumer terms, a free-tier API with
unreviewed terms, an unknown provider in an unknown region, a local
model on an unmanaged laptop and an unvetted browser plugin.
Direct API keys, personal AI accounts, free-tier APIs, unknown
providers, local models and browser plugins, all outside your
network edge.
Can you answer?
Which models touched our code?
Unknown
Where did our code go?
Unknown
Who approved the change?
Unknown
What is it costing us?
Unknown
With Eido Build
One policy for every engineer.
Diagram: inside your Azure tenant, the same ten engineers all
connect to Eido Build, which applies one policy with human approval
gates and reaches models through Microsoft Foundry: approved
models, with the hosting class shown and an audit trail kept.
Every engineer goes through Eido Build to Microsoft Foundry:
approved models, the hosting class shown, an audit trail kept.
Now you can
Which models touched our code? Your approved list
Where did our code go? Only where you approved
Who approved the change? A named person, every time
What is it costing us? Per release and work item
The platform
An engineering control plane, not a coding assistant.
Keep your process. Keep control. Choose your models.
Your Azure tenant
Deployed from Azure Marketplace
Orchestrator
Build
Schedules the work, holds the human gates, keeps the audit
trail.
Your agents
Windows 365 for Agents
Agent desktops with their own identity
Azure container workers
Ephemeral build, test and review compute
Model plane
Microsoft Foundry
The governed model plane, in your tenant
ClaudeAzure / partner
OpenAIAzure-hosted
MistralAzure-hosted
DeepSeekAzure-hosted
Open-weightYour compute
Choose where your agents run
Windows 365 for Agents gives each agent its own Entra joined, Intune enrolled desktop. Azure container workers spin up per job inside your network, under the Defender and Sentinel rules you already run.
Switch models, not the way you work
Claude, OpenAI, Mistral, DeepSeek or an open-weight model on your own compute, approved in Microsoft Foundry and picked per stage. If a provider doubles its price, change the model on that stage. No retraining, no rebuilt workflow, nothing else moves.
Humans stay in the loop, on gates you build
You draw the chain and name the approvers. Agents carry the work between the gates and stop at every one of them. Nothing passes a gate without a person’s name against it.
Cost
Stop budgeting AI per engineer. Start costing it per release.
A budget per engineer tells you who spent the money, never what it
bought. Eido Build records AI spend against the work: every release,
every work item, every stage.
Before Eido Build
A budget per engineer
$1,000per engineer, per month
AI usage
One block of spend.
At 200 engineers that is $2.4 million a year,
with no audit trail, no cost per work item and no way to drill in.
What you can see
Cost of a releaseNot recorded
Cost of a work itemNot recorded
Cost by modelNot recorded
With Eido Build
A cost per release
$414.40for release 24.10
$27.90 Customer dashboard redesign, one of 48 work
items
What you can see
Cost of a release$414.40
Cost of a work item$27.90
Cost by modelOpus $112.40Sonnet $268.90Haiku $33.10
The model fits the job
You choose a model for each stage of each pipeline. A typo fix does not have to run on the model that designs a feature.
Every stage has a cap
Each stage carries a maximum spend per run. You set it before any work starts.
Cost follows the work
Spend is recorded against the work item and the release it belongs to, so you can always see which work the money went on.
Your process
Build the process your company already trusts
Name the pipeline, describe each step in plain English, pick a model
your organisation has approved in Foundry and cap what it may spend.
Approvals are optional: gate the steps that matter and let the
agents run the rest unattended.
Pipeline builderNew feature
Pipeline name
New featuree.g. New feature
6 steps
01Design Opus ≤ $6 / run Product team “Design this feature end to end, including empty and error states.”
02Refine & Build Sonnet ≤ $12 / run Platform team “Implement it behind a feature flag and open a pull request.”
03SQL changes Sonnet ≤ $4 / run DBA team “Write the migration and a rollback script, no destructive changes.”
04Tests Sonnet ≤ $8 / run QA team “Add unit and integration tests, then run the whole suite.”
05Documentation Haiku ≤ $2 / run Product team “Update the customer docs and add a line to the release notes.”
06Merge Haiku ≤ $1 / runNo approval · automatic“Merge to main once every gate above is green.”
Add a step
Step composer
Plain English in, governed run out
New step
Step name
Mergee.g. Design
Instructions for the agent
Merge to main once every gate above is green.
Tell the agent what to do in this step
Model
Claude Haiku
Opusdeepest reasoning
Sonneteveryday build work
Haikufast and cheap
Max spend
$1/ run
Approval
optional
No approval, agents run it
Product team
Platform team
DBA team
QA team
No approval, agents run it
Leave approval off and the agents run this step unattended. Gate
only the steps your company needs a human on.
Add stepCancel
Always on
Agents running 24/7, finding bugs and finding ideas
Your agents read the systems you already run, work through the
night, and leave evidence-backed suggestions waiting for your team
in the morning.
Vulnerability Scannerchecking dependenciesrunning XSS checkstesting SQL injectionfuzzing API endpointschecking OWASP Top 10probing auth bypasstesting CSRF defenseschecking TLS configscanning for secretschecking dependencies
Zendesk Scanner clustering 214 tickets
Gong Scanner listening to 34 calls
Product Researcherreading 9 forum threadsscanning r/sysadminreading LinkedIn postssearching Microsoft Q&Acomparing release notesreading 9 forum threads
Security issue Urgent
Tenant data can leak between tenants
Code Scanner · missing tenant filter on 3 queries · waiting on Sam
Security issue
SQL injection in the device export filter
Vulnerability Scanner · from your codebase · waiting on Priya
Bug 18 tickets
Export times out above 50,000 devices
Zendesk Scanner · one root cause · waiting on Dan
Enhancement 34 calls
Let customers schedule their own reports by email
Gong Scanner · 11 accounts · waiting on Maya
Idea
Customers are asking for CSV export webhooks
Product Researcher · 18 suggestions across 3 forums
Build your own
Describe an agent in plain English
Say what the job is, what it may read, what it may spend and who
signs it off. The assistant turns that into a scheduled agent and
shows you every setting it chose before anything runs.
No connector for a system you use?
It writes the integration as well as the agent.
The new-agent screen: a plain English description of a weekly
win/loss review, with the schedule, data access, model and budget
the assistant filled in from it.
New agentDraft
What should it do?
Every week, look back at the deals we lost and the reasons we
lost them. Group the reasons, and suggest product changes that
would have won them. Attach the evidence.
Filled in from your description. Change anything before you create it.
Scheduled
Weekly
Every Monday at 02:00, Europe/London
Edit
Data it may read
SalesforceClosed-lost deals
GongCall transcripts
Deal desk APINo connector — writing one
AI model
Claude FableAzure-hosted
Approved for this project in Foundry. Swap it later without
rewriting the agent.
Budget per run−$4+
Create agent
Tenant-native
Built for Microsoft enterprises
Eido Build installs from Azure Marketplace into your own subscription
and runs on services your teams already govern. Not a Microsoft
product, built for the Microsoft stack.
Azure Marketplace
Installs into your own subscription. Your tenant, your policies.
Microsoft Entra ID
One identity model covering people and agents, with RBAC applied throughout. An agent signs in as itself, not as the developer who started it.
Windows 365 for Agents
Cloud PCs that are Entra joined and Intune enrolled, carrying their own agent identity, and reset after every session.
Microsoft Foundry
The governed model plane. Agents run on the models your organisation approves, with the hosting class recorded against every stage.
Azure Key Vault
Credentials stay in your vault and never reach an agent. Eido Build holds them, authenticates on the agent’s behalf, and hands it an interface instead of a secret.
Azure DevOps & GitHub
Agents work in your existing repositories and open pull requests there. Both first-class, not one bolted on afterwards.
Install Eido Build from Azure Marketplace into your own subscription and
take work from ticket to tested, review-ready code, with your process,
approvals and security controls intact.
Want to see it first? Watch it build a feature, fix a bug and set up
an always-on agent, along with the guard rails around all three.
Windows 365 for Agents
Microsoft Foundry
GitHub 
Azure DevOps 
Entra ID 
Intune 
Zendesk 
Gong 
Salesforce 
HubSpot