Before Foundry, building an AI agent meant stitching together a lot of moving parts yourself:<\/p>\n\n\n\n
- \n
- Managing conversation state between turns<\/li>\n\n\n\n
- Handling tool calling and parsing results<\/li>\n\n\n\n
- Storing and retrieving context across sessions<\/li>\n\n\n\n
- Dealing with infrastructure – compute, identity, secrets<\/li>\n\n\n\n
- Monitoring what your agent actually did<\/li>\n<\/ul>\n\n\n\n
That’s not impossible – I’ve done it manually – but it’s tedious, error-prone, and not the part of the problem you should be spending your energy on.
Azure AI Foundry Agent Service <\/strong>handles all of that. You focus on the agent’s purpose, instructions, and tools. Foundry handles the plumbing.<\/p>\n\n\n\nHow Foundry Is Structured<\/strong><\/p>\n\n\n\n
![\"\"](\"\/wp-content\/uploads\/2026\/04\/image-4-1024x569.png\")
<\/figure>\n\n\n\nSupporting resources connect underneath: Azure AI Search for retrieval, Azure Storage for files the agent reads and writes, Key Vault for secrets, and Azure Functions when you need custom tool logic.<\/p>\n\n\n\n
The Two Ways to Build: Portal vs. VS Code<\/strong>
This is a question I get in every discussion. Which approach is right?
<\/p>\n\n\n\nFoundry Portal (web-based):<\/em>
\u2705 No local setup required – spin up in minutes
\u2705 Visual configuration – great for prototyping and demos
\u2705 Centralised management dashboard
\u2705 Perfect for sharing with non-developer stakeholders
\u274c Less suited for complex code-first logic
\u274c Harder to version control
<\/p>\n\n\n\nVisual Studio Code (developer-centric):<\/em>
\u2705 Build agents alongside your application code
\u2705 Full Git integration – your agent config lives in version control
\u2705 YAML-based config – readable and diffable
\u2705 Offline development before deploying
\u274c Steeper setup curve
\u274c Not ideal for quick stakeholder demos
<\/p>\n\n\n\nMy practical advice: use both. Use the portal for initial exploration, concept validation, and stakeholder walkthroughs. Switch to VS Code once you’re moving toward production. Most teams I’ve worked with settle into this pattern naturally after a few weeks.<\/p>\n\n\n\n
The Typical Development Workflow<\/strong><\/p>\n\n\n\n
Here’s the 8-step workflow I teach, because seeing the shape of the whole process matters before diving into any single step:<\/p>\n\n\n\n
![\"\"](\"\/wp-content\/uploads\/2026\/04\/image-6.png\")
<\/figure>\n\n\n\nSteps 5 and 6 are where most of the real work happens. The playground in Foundry lets you have live conversations with your agent, inspect what tools it called, and see exactly how it reasoned through the problem. That feedback loop is fast – much faster than deploying code, testing, debugging, redeploy.<\/p>\n\n\n\n
What Foundry Handles So You Don’t Have To<\/strong><\/p>\n\n\n\n
This is the part I emphasise most with architects, because it changes the infrastructure conversation significantly:<\/p>\n\n\n\n
Concern<\/strong><\/td> Manual Approach<\/strong><\/td> With Foundry<\/strong><\/td><\/tr> Conversation state<\/td> You build a session store<\/td> Managed automatically via threads<\/td><\/tr> Tool calling<\/td> You parse LLM output and route calls<\/td> Handled by the agent runtime<\/td><\/tr> Retry logic<\/td> You implement it<\/td> Built in<\/td><\/tr> Scaling<\/td> You configure compute<\/td> Serverless, auto-scales<\/td><\/tr> Monitoring<\/td> You hook up Application Insights manually<\/td> Integrated telemetry<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n That’s a significant engineering shortcut – one that lets a team of two ship something that previously would have taken a team of six.<\/p>\n\n\n\n
Real-World Consideration: Cost and Governance<\/strong><\/p>\n\n\n\n
One thing the demos don’t always show: Foundry runs on top of Azure services, and each of those has a cost dimension.<\/p>\n\n\n\n
- \n
- Every LLM call costs tokens – monitor your model usage<\/li>\n\n\n\n
- Azure AI Search has its own SKU and query cost model<\/li>\n\n\n\n
- Functions and Storage are relatively cheap but add up at scale<\/li>\n<\/ul>\n\n\n\n
My recommendation<\/strong>: set up Azure Cost Management alerts from day one. Define a budget threshold per environment (dev\/test\/prod). I’ve seen perfectly good proofs-of-concept die in procurement because nobody tracked what the dev environment was spending for six weeks.
<\/p>\n\n\n\nAlso – governance. Know who can create agents, which models are approved, and what data those agents can access. These aren’t Foundry questions specifically; they’re organisational questions you need to answer before you scale.<\/p>\n\n\n\n
Pros and Cons of Foundry<\/strong>
Pros:<\/strong><\/p>\n\n\n\n- \n
- Genuinely reduces infrastructure complexity<\/li>\n\n\n\n
- Model-agnostic – swap LLMs without rewriting agent logic<\/li>\n\n\n\n
- Excellent playground for rapid iteration<\/li>\n\n\n\n
- Native Azure RBAC and identity integration<\/li>\n\n\n\n
- Growing ecosystem of connectors and integrations<\/li>\n<\/ul>\n\n\n\n
Cons:<\/strong><\/p>\n\n\n\n
- \n
- Azure lock-in – if you need multi-cloud agent portability, plan carefully<\/li>\n\n\n\n
- Some advanced customisations still require code<\/li>\n\n\n\n
- The UI evolves fast – documentation occasionally lags the product<\/li>\n\n\n\n
- Cost visibility requires proactive setup<\/li>\n<\/ul>\n\n\n\n
Foundry is not magic. You still need to think carefully about what your agent should and shouldn’t do, how failure cases are handled, and what happens when the LLM reasons incorrectly. But it removes a whole class of infrastructure problems from your plate, and for most enterprise teams, that’s exactly what’s needed to move from “AI proof-of-concept” to “AI in production”.<\/p>\n\n\n\n
Next up: I’ll walk through how to configure agent instructions properly – because the quality of what you put in the instructions field is what separates a useful agent from an expensive chatbot.<\/p>\n\n\n\n<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
Every time a new technology matures, a platform emerges that hides the complexity and lets you focus on the problem. Docker did it for containers. Kubernetes did it for orchestration. Azure AI Foundry is doing it for AI agents – and understanding what it actually handles for you is the first step to using it […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"_links":{"self":[{"href":"https:\/\/bogdanburuiana.com\/index.php\/wp-json\/wp\/v2\/posts\/1474"}],"collection":[{"href":"https:\/\/bogdanburuiana.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/bogdanburuiana.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/bogdanburuiana.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/bogdanburuiana.com\/index.php\/wp-json\/wp\/v2\/comments?post=1474"}],"version-history":[{"count":1,"href":"https:\/\/bogdanburuiana.com\/index.php\/wp-json\/wp\/v2\/posts\/1474\/revisions"}],"predecessor-version":[{"id":1478,"href":"https:\/\/bogdanburuiana.com\/index.php\/wp-json\/wp\/v2\/posts\/1474\/revisions\/1478"}],"wp:attachment":[{"href":"https:\/\/bogdanburuiana.com\/index.php\/wp-json\/wp\/v2\/media?parent=1474"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/bogdanburuiana.com\/index.php\/wp-json\/wp\/v2\/categories?post=1474"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/bogdanburuiana.com\/index.php\/wp-json\/wp\/v2\/tags?post=1474"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}