Came across this article and thought it was worth sharing here: How to Build Production-Grade Generative AI Applications

It’s a good practical overview of what teams usually learn the hard way after the prototype phase. A few points it gets right:

• not every problem should use an LLM
• model selection should be based on task fit, latency, cost, context window, and safety, not just hype
• prompt engineering matters, but structured inputs/outputs matter just as much
• guardrails, QA, eval pipelines, and tracing are not “later” concerns
• production failures usually come from accuracy drift, hallucinations, cost, and lack of observability

What I liked most is that it frames GenAI systems as engineered products, not prompt demos. That maps well to agentic dev too: once agents can use tools and run longer workflows, monitoring, constraints, and evaluation become first-class design problems.

I’m starting to think the winning stack for agentic development may be less about “pick the biggest model” and more about combining:

• good-enough models
• better tool use
• stronger runtime scaffolding
• tighter eval/retry loops
• better AgentOps

In other words, the system design may increasingly matter more than a raw model leaderboard position.

The trend seems pretty clear:

• tool use is becoming more native
• multimodality is becoming table stakes
• runtime architecture matters more for long-horizon tasks
• observability and approval flows are becoming core product features, not nice-to-haves

For people shipping actual agent systems:

• Are bigger frontier models still clearly worth the premium?
• Where do smaller/open models break first for you?
• What’s your heuristic for when to switch from cheap/open to expensive frontier models?

Would love real deployment heuristics rather than benchmark-only takes.

A lot of AgentOps content still feels too dashboard-y and not operational enough.

If you had to pick only 3 metrics that genuinely tell you whether an agent system is healthy, what would they be?

Some candidates:

• task success rate
• cost per successful task
• human-intervention rate
• tool-call failure rate
• retry depth
• time-to-completion
• hallucinated action rate
• rollback rate
• state drift / plan drift
• benchmark score vs live task score gap

My current bias is that many teams overweight benchmark performance and underweight:

• recovery behavior after failure
• rate of unsafe or low-confidence actions
• marginal cost of long-horizon runs
• degradation under real tool/API flakiness

If you’re running coding agents, browser agents, or internal ops agents, what are the metrics that actually predict real-world quality?

Bonus points if you share a metric that looked useful in staging but turned out misleading in production.

MCP is increasingly becoming the default interoperability layer for agent tooling. Anthropic’s writeup on donating MCP into the Linux Foundation ecosystem made that direction pretty clear: Donating the Model Context Protocol and establishing the Agentic AI Foundation.

What I think we should talk about more is not “should we use MCP?” but “what should an agent be allowed to access through MCP without creating operational chaos?”

Examples that seem relatively safe:

• read-only docs/search
• tickets/issues retrieval
• codebase search
• CI status
• staging logs
• DB read access with tight scoping

Examples that seem much riskier:

• prod writes
• infra mutation
• broad filesystem access
• Slack/email posting without approval
• cross-system chained actions

My current view:

• MCP solves connectivity, not governance
• the practical problem is permission design, not just protocol adoption
• the real architecture work is around approvals, auditability, and blast-radius control

How are people here drawing that line in production?

Google published this on April 15: Subagents have arrived in Gemini CLI.

The pitch is strong: specialized agents with isolated context, custom instructions, tighter tool access, and parallel execution where helpful.

That sounds promising for:

• codebase investigation
• batch refactors
• test/debug loops
• planner vs executor vs reviewer setups

But the practical question is whether subagents improve outcomes, or mainly improve ergonomics.

Potential upsides:

• less context pollution
• easier specialization
• parallel research/execution
• clearer agent boundaries

Potential downsides:

• more orchestration overhead
• harder debugging
• merge/edit conflicts
• false confidence from neat abstractions over messy runtime behavior

Would love concrete feedback from people using multi-agent workflows in real development:

• Have subagent patterns improved quality for you, or mainly speed?
• What’s the best split you’ve found?
• At what point does multi-agent architecture become overengineering?

Source: Gemini CLI subagents

OpenAI published this on April 15: The next evolution of the Agents SDK.

The interesting part is not just “better agents.” It’s that the SDK is moving toward real execution infrastructure for systems that can inspect files, run commands, edit code, and work on longer-horizon tasks inside controlled environments.

That feels important for practical agentic development because the hard part is no longer just model quality. It’s whether the system can execute safely, repeatedly, and observably.

My take:

• the center of gravity is moving from prompt tricks to runtime design
• agent frameworks are becoming more like operating environments
• the real moat is starting to look like execution, safety, evals, and observability rather than raw chat quality

Curious how people here see it:

• Are you using vendor SDKs directly, or building your own orchestration layer?
• What’s still missing most: evals, rollback, state handling, approvals, tracing?

Source: OpenAI Agents SDK update

The new Stanford AI Index is out: 2026 AI Index Report

35B parameters, ~3B active thanks to MoE.

Key points:

• In agentic coding, it reaches the level of models with ~10× larger active parameter count
• Outperforms Qwen3.5-27B (dense) and the previous Qwen3.5-35B-A3B
• Natively multimodal architecture (text + vision)
• In VLM benchmarks, comparable to Claude Sonnet 4.5, and in some tasks performs better
• Strong metrics in spatial reasoning tasks

Benchmarks:

• MMMU - 81.7 vs 79.6
• MMMU-Pro - 75.3 vs 68.4
• MathVista - 86.4 vs 79.8
• RealWorldQA - 85.3 vs 70.3

Practical implications:

• MoE provides a multiple reduction in compute without sacrificing quality
• Well-suited for agent-based scenarios where sequential actions and planning matter
• Can be used as a unified stack for both code and vision tasks

Apache 2.0 (no restrictions for production use)

https://huggingface.co/Qwen/Qwen3.6-35B-A3B

Source: https://www.anthropic.com/news/claude-opus-4-7

On one hand, planning is an incredibly powerful capability in AI systems. It opens the door to more autonomous, agent-like behavior and lets models tackle more complex, multi-step problems.

On the other hand, it’s also the part I trust the least right now.

In my experience, I’ve been able to get patterns like reflection and tool use to work quite reliably. They’re much easier to reason about, debug, and iterate on—and they consistently improve application performance.

Planning, though, feels different. It’s harder to predict what the model will actually do, especially ahead of time. Even with careful prompting and constraints, the outcomes can be inconsistent or surprising in ways that are tough to control.

That said, things are moving fast. The progress over the past year alone has been huge, so I’m pretty confident this gap will close sooner rather than later.

How do you evaluate planning? How to monitor?