Updating AI Workflows for Latest LLM Releases

I started by asking AI to do everything. Six months later, 65% of my agent’s workflow nodes run as non-AI code. The first version was fully agentic : every task went to an LLM. LLMs would confidently progress through tasks, though not always accurately. So I added tools to constrain what the LLM could call. Limited its ability to deviate. I added a Discovery tool to help the AI find those tools. Better, but not enough. Then I found Stripe’s minion architecture. Their insight : deterministic code handles the predictable ; LLMs tackle the ambiguous. I implemented blueprints, workflow charts written in code. Each blueprint specifies nodes, transitions between them, trigger conditions for matching tasks, & explicit error handling. This differs from skills or prompts. A skill tells the LLM what to do. A blueprint tells the system when to involve the LLM at all. Each blueprint is a directed graph of nodes. Nodes come in two types : deterministic (code) & agentic (LLM). Transitions between nodes can branch based on conditions. Deal pipeline updates, chat messages, & email routing account for 29% of workflows, all without a single LLM call. Company research, newsletter processing, & person research need the LLM for extraction & synthesis only. Another 36%. The workflow runs 67-91% as code. The LLM sees only what it needs : a chunk of text to summarize, a list to categorize, processed in one to three turns with constrained tools. Blog posts, document analysis, bug fixes are genuinely hybrid. 21% of workflows. Multiple LLM calls iterate toward quality. Only 14% remain fully agentic. Data transforms & error investigations. These tend to be coding tasks rather than evaluating a decision point in a workflow. The LLM needs freedom to explore. AI started doing everything. Now it handles routing, exceptions, research, planning, & coding. The rest runs without it. Is AI doing less? Yes. Is the system doing more? Also yes. The blueprints, the tools, the skills might be temporary scaffolding. With each new model release, capabilities expand. Tasks that required deterministic code six months ago might not tomorrow.

𝗜𝗳 𝘆𝗼𝘂 𝘀𝘄𝗮𝗽𝗽𝗲𝗱 𝘆𝗼𝘂𝗿 𝗟𝗟𝗠 𝘃𝗲𝗻𝗱𝗼𝗿 𝘁𝗼𝗺𝗼𝗿𝗿𝗼𝘄, 𝘄𝗼𝘂𝗹𝗱 𝘆𝗼𝘂𝗿 𝗔𝗜 𝗮𝗴𝗲𝗻𝘁𝘀, 𝘁𝗼𝗼𝗹𝘀, 𝗮𝗻𝗱 𝘄𝗼𝗿𝗸𝗳𝗹𝗼𝘄𝘀 𝘀𝘁𝗶𝗹𝗹 𝘄𝗼𝗿𝗸... 𝗼𝗿 𝘄𝗼𝘂𝗹𝗱 𝗲𝘃𝗲𝗿𝘆𝘁𝗵𝗶𝗻𝗴 𝘀𝗻𝗮𝗽 𝗶𝗻 𝗵𝗮𝗹𝗳? Over the last few weeks, MCP (Model Context Protocol) has quietly gone from “cool open-source project” to real infrastructure for solving that exact problem:  • Microsoft just moved MCP support for Azure Functions to GA, with identity-aware, streamable tool triggers so agents can call serverless functions safely.   • Google announced official MCP support across Google Cloud services, with fully managed MCP servers for BigQuery, GKE, GCE and more.  • Anthropic donated MCP to the Agentic AI Foundation under the Linux Foundation, alongside OpenAI’s AGENTS.md and Block’s goose, making MCP a neutral, open standard that looks a lot like the “HTTP moment” for agentic AI. This is bigger than plumbing; it’s a shift in how we architect agents: 𝗧𝗼𝗼𝗹𝘀 𝗯𝗲𝗰𝗼𝗺𝗲 𝗽𝗿𝗼𝗱𝘂𝗰𝘁𝘀,𝘁𝗵𝗲 𝗽𝗿𝗼𝘁𝗼𝗰𝗼𝗹 𝗯𝗲𝗰𝗼𝗺𝗲𝘀 𝘁𝗵𝗲 𝗽𝗹𝗮𝘁𝗳𝗼𝗿𝗺 𝗮𝗻𝗱 𝘁𝗵𝗲 𝗺𝗼𝗱𝗲𝗹 𝗯𝗲𝗰𝗼𝗺𝗲𝘀 𝗮 𝗿𝗲𝗽𝗹𝗮𝗰𝗲𝗮𝗯𝗹𝗲 𝗰𝗼𝗺𝗽𝗼𝗻𝗲𝗻𝘁. If you’re building enterprise AI agents, here’s how I’d think about MCP and standardized workflows:  1. 𝗗𝗲𝗳𝗶𝗻𝗲 𝘁𝗼𝗼𝗹𝘀 𝗮𝘀 𝗰𝗼𝗻𝘁𝗿𝗮𝗰𝘁𝘀, 𝗻𝗼𝘁 𝗵𝗲𝗹𝗽𝗲𝗿𝘀: treat each MCP tool as a versioned, testable API surface with strict schemas, auth scopes, and SLAs, not as a “convenience wrapper” hidden inside prompt code.  2. 𝗦𝗲𝗽𝗮𝗿𝗮𝘁𝗲 𝗼𝗿𝗰𝗵𝗲𝘀𝘁𝗿𝗮𝘁𝗶𝗼𝗻 𝗳𝗿𝗼𝗺 𝗶𝗻𝗳𝗲𝗿𝗲𝗻𝗰𝗲: let your workflow engine (orchestrator) own state, routing, retries, and compensations, and let MCP tools + models handle reasoning and side effects behind that control plane.  3. 𝗖𝗲𝗻𝘁𝗿𝗮𝗹𝗶𝘇𝗲 𝗴𝗼𝘃𝗲𝗿𝗻𝗮𝗻𝗰𝗲 𝗮𝘁 𝘁𝗵𝗲 𝗽𝗿𝗼𝘁𝗼𝗰𝗼𝗹 𝗯𝗼𝘂𝗻𝗱𝗮𝗿𝘆: enforce identity, permissions, rate limits, tenant isolation, and audit logging at the MCP layer so every model and agent inherits the same guardrails by design.  4. 𝗗𝗲𝘀𝗶𝗴𝗻 𝗳𝗼𝗿 𝗺𝗼𝗱𝗲𝗹 𝗮𝗻𝗱 𝘃𝗲𝗻𝗱𝗼𝗿 𝗺𝗼𝗯𝗶𝗹𝗶𝘁𝘆: write conformance tests at the MCP level so you can plug different LLMs or agent runtimes into the same tool graph without re-wiring business logic.  5. 𝗠𝗮𝗸𝗲 𝘄𝗼𝗿𝗸𝗳𝗹𝗼𝘄𝘀 𝗠𝗖𝗣-𝗻𝗮𝘁𝗶𝘃𝗲, 𝗻𝗼𝘁 𝗺𝗼𝗱𝗲𝗹-𝗻𝗮𝘁𝗶𝘃𝗲: when you design a new agentic workflow, start by asking “what MCP tools and flows do we expose?” rather than “what should this model prompt say?” so your investment lives in protocols, not in one provider’s SDK. If MCP is the “USB-C for AI agents,” the 𝗿𝗲𝗮𝗹 𝗱𝗶𝗳𝗳𝗲𝗿𝗲𝗻𝘁𝗶𝗮𝘁𝗼𝗿 won’t be who has the flashiest agent demo—it’ll be who designs the cleanest, most 𝗴𝗼𝘃𝗲𝗿𝗻𝗮𝗯𝗹𝗲 𝗠𝗖𝗣-𝗻𝗮𝘁𝗶𝘃𝗲 𝘄𝗼𝗿𝗸𝗳𝗹𝗼𝘄𝘀 across their stack.

Do LLMs keep giving you outdated code examples? That's not their fault; they can't read docs from 2025. But with modern tooling, building a system that keeps LLM agents synced... The problem I kept hitting I work at Weaviate, and our Python client syntax is regularly updated with new features and improvements. But LLMs' training data are frozen in time. Developers ask for code examples and get confident responses with syntax from 2023 that no longer works. So this weekend, I hacked something together to show you how to fix it. The stack I put together: - Crawl4AI scrapes documentation sites - Weaviate stores chunked content with embeddings - #MCP server exposes search as a Claude tool - Pydantic AI builds agents that query live docs The result? Claude searches current documentation and cites sources. Every code example reflects the latest syntax. I started with Weaviate's docs since I know them well, but the pattern generalizes to any evolving documentation: → Internal company wikis → API docs (Stripe, Twilio, AWS, whatever) → Framework docs that change with each release → Any knowledge base that needs to stay current The whole project is under ~200 lines of code, split into 5 files. Check it out! https://lnkd.in/ecJC3m6C

OpenAI just launched GPT-5.1, which fixes the things that broke your workflows. There are two new modes: Instant is faster and better at simple tasks, while Thinking uses adaptive compute allocation to improve reasoning and reduce the wobble that emerged in GPT-5’s first months. This release is a stability upgrade for teams that use GPT-5 in production. According to OpenAI, GPT-5.1 follows instructions more reliably. Structured tasks run cleaner. Formats hold. Step-based logic fails less often. This is probably its biggest real-world improvement. OpenAI also added tone presets. Friendly, Efficient, and Candid help teams lock tone across customer interactions without manual tuning. We will test both modes over the next few days, and you should do the same with your workflows so you can decide whether the improvements justify a full rollout. OpenAI says Thinking mode will reduce errors in agent-driven tasks, and Instant mode will cut latency in customer service tools, field operations, and internal knowledge systems. The company also says the model is less brittle, which should make prompt catalogs easier to maintain. You still need governance. You still need red-team testing. You still need humans in the loop. Run your high-value workflows against 5.1 in Thinking mode. Measure accuracy, hallucination rate, and consistency. Validate the agent-driven tasks that depend on predictable reasoning. Update your tone governance to account for the new presets. Retraining is inevitable; some prompts we built for GPT-5 already behave differently. After you fix what GPT-5.1 breaks, OpenAI says it will strengthen your AI stack. Treat this release as a maintenance upgrade, as that’s what it looks like.

LLMOps is becoming the new DevOps for AI engineers. Getting a prompt to work is the easy part. The real challenge is making your LLM applications repeatable, scalable, and reliable in production. That’s where LLMOps comes in. Think of it as the operating system for LLM-driven applications, from data prep to responsible deployment. Here are the core components of an LLMOps pipeline (see diagram 👇): ➡️ Model Customization: data preparation, supervised fine-tuning, evaluation ➡️ Behind the Scenes: foundation + fine-tuned models, pre-processing, grounding with external knowledge, post-processing with responsible AI filters ➡️ LLM Response Layer: prompting, user interaction, and outputs ➡️ Pipelines: orchestration (data versioning, configs, workflow design) and automation (deployment, execution, monitoring) As engineers, the craft isn’t just in building the model, it’s in building the system around the model. 💡 Here are some excellent repos/resources to explore: 👉 Prompt orchestration & pipelines → Haystack, LangGraph 👉 Evaluation & Responsible AI → Ragas, LlamaIndex evals 👉 Data prep & tuning → OpenPipe, Axolotl 👉 Deployment → vLLM, Ray Serve, Fireworks AI If you’re building production-grade AI, don’t stop at the model. Learn to think in terms of LLMOps pipelines- orchestration, automation, and continuous improvement. 〰️〰️〰️ Follow me (Aishwarya Srinivasan) for more AI insight and subscribe to my Substack to find more in-depth blogs and weekly updates in AI: https://lnkd.in/dpBNr6Jg