I have spent enough years watching people love GraphQL for the wrong reasons and hate it for the wrong reasons that I want to step around both of those piles entirely and talk about the one place where I think it is genuinely, quietly excellent. Not GraphQL as your public edge. Not GraphQL as a REST replacement. Not GraphQL because a frontend team wanted to stop waiting on backend tickets. I mean GraphQL as connective tissue — the seam that stitches a pile of mismatched REST APIs, event streams, and internal services into one coherent graph a consumer can actually reason about. That is the job it was born for, and it is the job the marketing and the backlash both keep talking you out of noticing.

Here is the situation almost every organization of any size is actually in. You do not have an API. You have forty of them. You have a REST API that a team built in 2018, a newer one somebody wrote in a hurry last year, a couple of AsyncAPI-described event streams throwing messages onto a broker, a gRPC service two teams down, and a SaaS product or three whose APIs you do not control at all. A consumer who wants to answer one useful question — give me this customer, their last five orders, their open support tickets, and whether their latest event stream shows churn risk — has to touch five of those surfaces, each with its own auth, its own shape, its own idea of what a customer even is. That is not an API problem you can lint your way out of. That is a composition problem, and composition is exactly what GraphQL’s type system is good at.

When GraphQL sits in the middle as a federated graph, it becomes a place where all of those heterogeneous backends get expressed as one set of types with real relationships between them. The REST customer, the streamed churn signal, and the SaaS ticket stop being three unrelated calls and become three fields hanging off the same node. The consumer asks one question and gets one shaped answer, and the ugly work of fanning out to five backends, translating five payloads, and reconciling five notions of identity happens inside the graph where it belongs. This is the same instinct I keep coming back to when I argue that GraphQL is governance by default — the schema forces you to actually decide what your things are and how they relate, and when you are stitching together a dozen backends, being forced to decide is a feature, not a tax.

I want to be precise about the boundary, though, because this is where people overreach and give GraphQL its bad name. The connective-tissue role is an internal orchestration and aggregation role. It is the layer that composes. It is not automatically the right thing to expose raw to the whole internet, it does not make your caching problems disappear — it usually makes them harder — and it does not absolve you of the underlying APIs. The REST services underneath still need to be well-designed, well-governed, and durable, because GraphQL is stitching them, not replacing them. A federated graph over a pile of bad APIs is a tidy front on a mess. The connective tissue is only as healthy as the muscle it connects.

And this is the part that ties GraphQL back into everything I have been writing about agents and MCP being last-mile plumbing. When an agent shows up wanting to do a real job across your estate, the thing it most needs is not forty disconnected surfaces — it is one composed surface where the relationships are already expressed. A federated GraphQL layer is one of the cleanest ways to give it that. It is a single typed graph that already knows a customer has orders and tickets and events, so the agent does not have to rediscover those relationships by trial and error against five APIs. The connective tissue that makes life easier for a human integrator makes life dramatically easier for a machine one, because the machine is even less equipped to guess how your five backends secretly relate.

So my honest position on GraphQL, after all these years, is neither the hype nor the hate. It is that GraphQL earns its keep as a composition layer — the connective tissue over a heterogeneous estate of REST, events, and third-party APIs — and it struggles or actively hurts when you deploy it as a fashion statement, a public edge you have not thought through, or a way to avoid designing the APIs underneath. Put it in the middle, where it stitches, and it is one of the better tools we have. Put it at the edge for the wrong reasons and you will spend the next two years re-learning why REST was the right answer for the thing you replaced. The tissue is not the muscle, and it is not the skin. It is the connective layer in between, and that is exactly where it belongs.

Open weight models are having a moment, driven by control, choice, and cost. Hybrid and local AI are now getting serious looks, so JetBrains teamed up with DeepLearning.AI on a free AI Coding Workflows: Hybrid to Local course that covers the ideas and options.

The course is now available and uses PyCharm and its AI Chat. Here’s a peek into the course.

Claude Code: Subagents and cheaper models

We start the course with, well, not-local. Instead, we use what you already know – Claude Code and its Anthropic models – to introduce some of the techniques and “levers” that help bring choice, control, and even cost reduction. (Yes, I wrote emdashes.)

We did a previous course on Spec-Driven Development (SDD) so of course, we wanted to start there. Smaller models struggle with big, open-ended “vibe coding.” Dividing and bounding the work keeps smaller models on track. Important note: this course’s example app is really basic. You might say “that’s too easy.” But that’s part of the takeaway: big brain models can do the upfront work, forming right-sized steps for smaller models.

We then illustrate this division with a Claude Code subagent. The main chat prompt implements each roadmap phase in a fresh subagent, to better manage context. This then gives the payoff: a cheaper model for the implementer. Use a “big brain” (Opus) for main conversation thinking and a “little brain” (Haiku) for implementation.

Each lesson finishes with metrics about the change in tokens, turns, cost, and estimated wall time. Which brings us to the main course goal: learning the ideas instead of the specifics, which change weekly.

New agent, inference, and model

That covers the four levers:

• Specs shaped for the model size
• Specialist subagents to divide work
• Cheaper models for the routine work
• Collect metrics as evidence to guide thinking

The course then introduces choice and control:

• New agent: OpenCode
• New inference router: OpenRouter
• New model and inference host: DeepSeek (via OpenRouter) by moving to a new agent (OpenCode) using inference routing (OpenRouter) to inference hosting and models (DeepSeek)

We first move to OpenCode, running in PyCharm. JetBrains wants our IDEs to be open platforms for agents and models. This makes the move from Claude Code to OpenCode straightforward: it’s the same UI. We add OpenRouter (a paid step), connect it to OpenCode, and choose DeepSeek as a model.

Next we repeat our sequence: all in one chat, then context isolation using a subagent. But this time, with a different agent and model.

We finish by making a dedicated implementer subagent in Markdown. This gives quite a number of levers of control: in the frontmatter for mandatory controls, and in the subagent body for “persuasion” guidance. Most importantly, we have the implementer use the smaller DeepSeek v4 Flash model as the “little brain.”

Compared to the Claude Code version, the metrics were, unsurprisingly, a lot cheaper.

Hybrid and Local

Now for the main attraction: for routine development, can we do some – or even all – of the work locally?

We start with a lesson on setting up local AI: LM Studio as the inference server and Gemma 4 12B as the local model, targeting a 32 GB laptop.

We then configure the implementer subagent to use this local Gemma 4 model, promoting DeepSeek v4 Flash from last lesson’s “little brain” up to “big brain.” The results? Quite good, as it turns out.

Then the big test: fully local, with Qwen 3.5 27B as the “big brain.” The results: better than expected, showing that guardrails help.

How did hybrid and local do? Both of these lessons finish with a review of the metrics. That’s one of the big course takeaways: look at the evidence. You can see how small models struggle, and see the effect of helping them succeed.

Hybrid and Local AI Are Heating Up

Much thanks to DeepLearning.AI both for working with us again and for pushing to get this out fast. This topic is now red-hot in the news: Sovereign AI, privacy and security, and of course cost. The innovations are coming really fast and it is important to have a gentle introduction to the fundamentals.

We’ll do more updates here on Local AI for control, choice, and cost. Most of all, we at PyCharm believe in the human-in-the-loop. Stay tuned for more on this.

Wasim Osman: The Scrum Master as a Router, Redefining Success Through Efficient Communication

Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.

 

"A big part of the Scrum Master role is to work as a router—handling a lot of conversations with a lot of different devices, even though the internet is coming in through one cable." - Wasim Osman

 

For Wasim, success as a Scrum Master looks like a router in a house: many conversations, many stakeholders, all flowing through one point that has to prioritize, schedule, and stay on time. If the router slows down, everything downstream stalls—and the Scrum Master becomes the blocker. Early in his career he was overwhelmed juggling three or four engineering teams, so he built himself a personal Kanban board and ran his own quick standup every morning and again at the end of the day, just to see what moved, what stalled, and why. Getting organized with himself is when the work started to feel satisfying, because he stopped being the bottleneck. But he's honest about the hardest part: people rarely tell you to your face when you're slowing them down. The feedback is already there—you're just not hearing it. So you have to ask for it, react well when you get it (or people stop offering), and sometimes name the awkward truth first: "Our meetings used to be better—what happened?" That opening gives everyone permission to be honest.

 

Self-reflection Question: If you're the "router" for your teams, where are you quietly becoming the bottleneck—and who would tell you if you were?

Featured Retrospective Format for the Week: What Went Well / What Went Wrong / Outliers + Open Discussion

Wasim's go-to retrospective is deliberately bare-bones: what went well, what went wrong, and—the part that makes it his own—what were the outliers, followed by open discussion. He added the "outliers" question years ago after noticing that team members kept raising points that weren't clearly good or bad, but were still significant enough to discuss. Outliers give people "a bucket for sharing information that has no polarity"—an early signal about the future, a quiet concern, something that doesn't fit the other two columns but matters. He sometimes pairs it with lightweight metrics: sprint completion rate, or tickets that sat too long in review or QA, surfacing patterns the team wouldn't otherwise notice.

 

Self-reflection Question: What "outlier" signal has your team been sitting on—neither a win nor a problem yet—that deserves an open conversation before it becomes one?

 

[The Scrum Master Toolbox Podcast Recommends]

🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥

Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people.

 

🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue.

 

Buy Now on Amazon

 

[The Scrum Master Toolbox Podcast Recommends]

 

About Wasim Osman

 

Wasim Osman is a seasoned Agile Coach and a Product Owner at Orkestra SCS. He launched his agile career at a Silicon Valley startup based in New York, then spent years coaching teams across Canada, helping organizations transform how they deliver value. Wasim brings a rare blend of agile discipline and product thinking. He's passionate about building technology that drives real business impact.

 

You can link with Wasim Osman on LinkedIn.

 

Download audio: https://traffic.libsyn.com/secure/scrummastertoolbox/20260813_Wasim_Osman_Thu.mp3?dest-id=246429

---

---

Microsoft AI just introduced MAI-Thinking-1, their first reasoning model – and it is already in the Microsoft Foundry model catalog in public preview. Announced August 12, 2026, this is MAI’s own reasoning model, trained from the ground up, not distilled from anyone else’s models.

And yes – I of course tested it out. I already deployed it to my own Microsoft Foundry, so let’s take a closer look at what it is and why it matters for Future Work.

MAI-Thinking-1

MAI-Thinking-1 is a reasoning model: you give it a prompt, and it produces an internal chain of thought before it answers. The interesting part is that it allocates the reasoning effort adaptively based on how complex your prompt is. Simple question, less thinking. Hard question, more thinking. That is exactly the kind of behavior you want when you are paying per token.

Under the hood it is a sparse Mixture-of-Experts (MoE) Transformer with 35B active and ~1T total parameters. MoE means only the parts of the model needed for each request get activated – capability scales up without compute scaling linearly with it. Microsoft calls it a medium-sized model that stands among the strongest in its weight class.

Some key numbers:

• 256K context window – Microsoft notes that is enough to fit a 600-page document
• Function calling and support for developer instructions
• Built on the widely used Chat Completions API, so migration is meant to be easy
• Training cut-off: July 2026
• Text-only – no image, audio or video in or out

Work is changing. And the models we build our agents on are changing even faster.

The benchmarks

Microsoft is not claiming this is the biggest model on the planet. They are claiming it is the best in its weight class, and the numbers they published back that framing up:

• 97.0% on AIME 2025 and 94.5% on AIME 2026 – serious mathematical reasoning
• Toe-to-toe with Claude Opus 4.6 on SWE-Bench Pro for agentic coding
• Preferred over Claude Sonnet 4.6 in a blind human side-by-side evaluation run with their partner Surge, spanning 1,276 tasks in single-turn and multi-turn conversations

That last one is the one I find most interesting. Benchmarks measure capability, but that human preference evaluation measures whether the model actually understands the task, follows the instructions, uses the right level of detail and respects your time. That is the stuff that decides whether people keep using an agent you built – or quietly go back to doing it by hand.

Clean data

This is the part I think enterprises should read twice. Microsoft trained MAI-Thinking-1 without distillation from third-party models, on data they describe as clean, traceable and enterprise-grade, appropriately licensed.

Why does that matter to you and me? Because provenance is becoming a governance question, not just a research one. When your legal, compliance or security people ask “what shaped this model?”, “we can account for it” is a very different answer than “it learned from another model that learned from something else”. Quality, provenance, control – that is the pitch, and it is a good one.

Microsoft frames this as part of their broader work towards Humanist Superintelligence: AI designed to serve people and organizations, not replace them. They also make a point I really like – that a model refusing legitimate requests under the guise of safety is a defect too, not a feature. They train unsafe compliance and unnecessary refusal as defects in the same reward system. Anyone who has ever been refused by an AI for asking something completely normal knows exactly why that matters!

Pricing

MAI-Thinking-1 is priced at $2 USD per 1M input tokens and $8 USD per 1M output tokens.

That is the whole bet, really: strong reasoning at a price-performance point that makes high-volume, always-on AI workloads economically viable. Because here is the thing about agents – the pilot is never the expensive part. The expensive part is when it works, everyone starts using it, and it runs all day every day across the organization. A reasoning model that is affordable enough to leave running is a different proposition than one you only bring out for special occasions.

Combine that with adaptive reasoning effort and you get a model that does not burn tokens thinking hard about easy questions. Smart, like really smart.

Direct from Azure – what that means

MAI-Thinking-1 is a Direct from Azure model in Microsoft Foundry. In practice:

• Secured and managed by Microsoft – single license, consistent support, no third-party dependencies
• Unified billing and governance, with PTU portability across models hosted on Azure
• Pay-as-you-go flexibility, or reserve PTUs when you want predictable performance and savings
• Test, deploy and switch between models inside one platform

It also plugs into Foundry’s integrated evaluation, observability, safety and deployment capabilities. If you are building agents for real production use, that surrounding toolset matters at least as much as the model itself.

MAI-Thinking-1 is available on various other regions also, I could not screenshot them all at once so I selected some regions. The point: it is quite widely available, but there are some regions that don’t have it.

Where I would actually use it

Microsoft calls out three use case areas, and all three are very recognizable from real customer work:

• Enterprise deployments – 256K context, clean data provenance, function calling, complex instruction following
• Coding workflows – reading code, editing files, running tests, bug fixing, observing failures and recovering from intermediate mistakes
• Complex reasoning – especially quantitative work like financial modeling, statistical analysis, market sizing and forecasting

That 256K context window is the one I keep coming back to (although it is not 1M like with Claude..). Long agent traces without chunking and stitching them together is a genuine quality-of-life improvement when you are building multi-step agents. Anyone who has built a workflow that had to summarize its own history to survive knows the pain.

Notes

It is public preview, so treat it accordingly – this is for testing and building, not for betting your production workload on today.

A few more things worth knowing before you deploy:

• It is not designed as an autonomous decision-maker in consequential domains – legal, financial, medical, employment, educational, housing, credit, safety-critical. Not a substitute for professional advice in regulated fields.
• It has no native tool interface. Tool use is mediated entirely by your application, which means you own the security boundary around anything you expose to it. Please read that sentence again if you are building agents.
• It is not evaluated for fully autonomous agentic deployments acting on untrusted external content without human oversight or harness-level controls.
• Language coverage varies. It is primarily optimized for English, and also supports German, Spanish, French, Italian, Portuguese, Chinese (Simplified), Russian, Hindi, Japanese, Korean, Arabic and Hungarian, with more limited coverage for Hebrew, Turkish, Persian, Thai, Vietnamese, Indonesian and Ukrainian among others.

Try MAI-Thinking-1 in Microsoft Foundry Public Preview API and Playground are available. Deployment was genuinely easy – find it in the catalog, deploy, and you are testing in minutes. Setup could not be much simpler.

Verdict

MAI-Thinking-1 is not trying to be the biggest model in the room. It is trying to be the one you can actually afford to run all day – and that is a much more useful ambition for the kind of work most of us are doing right now. Strong reasoning, real agentic coding chops, a 256K window, clean and traceable data, and $2/$8 per million tokens.

For me the most exciting signal is not the benchmark table at all. It is that Microsoft is building its own reasoning capability from the ground up, on data it can account for, inside the same Foundry platform where the evaluation, observability and governance already live. That is a very different foundation to build enterprise agents on than we had even a year ago.

I am also waiting and hoping that this model will come to Copilot Cowork soon, as it will help to lower costs using Cowork!

Have you already deployed MAI-Thinking-1 in your own Foundry? I would like to hear what you are building with it – drop a comment and let me know!

---

Sources: Introducing MAI-Thinking-1 | Microsoft AI · MAI-Thinking-1 in the Microsoft Foundry model catalog

---