A model change can push token usage up 8x, while retry-heavy agent loops can burn through budget before conventional billing alerts catch the problem. The discussion looks at how FinOps can move closer to the engineering workflow as AI usage scales.

• Predictive budgets can flag teams or service accounts heading far beyond quota early in the month, giving engineers time to adjust rather than simply hitting a hard stop.
• FinOps checks can be built into system prompts, pull requests, and deployment workflows, surfacing policy, model, and infrastructure costs as code changes.
• Some workflows may be better served by rules, retrieval, or conventional ML, with LLMs reserved for the steps that genuinely need generation.

The core idea is to make cost an engineering signal that appears early enough to shape architecture, model choice, and day-to-day decisions.

A workflow that cost $1 per 1,000 records at 90% accuracy reached 95% accuracy while costing less, after an optimizer moved 75% of the work out of the model and into code. That result sits inside a broader discussion about when agentic behavior should become a defined workflow.

• Models increasingly inherit assumptions from the coding harnesses they were trained around, which can make custom harnesses harder to build.
• Repeated agent tasks can often be “crystallized” into smaller models or conventional code once the process is understood.
• DSPy separates task definitions from implementation, allowing prompts, models, and even harness code to be optimized without redefining the task.

The practical direction is toward identifying which tasks still need open-ended agents and which are mature enough to become cheaper, more reliable workflows.

Sticky sessions and shared session stores are no longer required under MCP’s 2026-07-28 specification, removing a major obstacle to scaling remote servers across multiple instances. The same release cycle also brings centralized enterprise authorization and a more predictable protocol lifecycle.

• The stateless core makes every request self-describing, enabling standard round-robin load balancing and multi-round-trip interactions without persistent sessions.
• Enterprise-managed authorization uses ID-JAG and token exchange to connect existing SSO, roles, and audit controls to MCP servers.
• Formal deprecation windows, conformance testing, and beta SDKs give teams a clearer path for testing and migrating between protocol versions.

The changes move MCP closer to infrastructure that teams can scale, govern, and upgrade using established production patterns.

A read-only inventory agent can still have more authority than the task requires if its shell or cloud credentials are too broad. This design walkthrough uses goose to show how OKE and AKS inventory could be constrained without giving the model write-capable access, while clearly separating planned behavior from validated results.

• The prototype combines read-only cloud identities, supervised shell access, and two exact inventory commands, while acknowledging that recipe instructions are not a technical allowlist.
• Structured output preserves partial failures, unknown values, warnings, and provenance, with independent logs needed to verify what actually ran.
• A stronger production boundary would replace the general shell with narrow MCP tools that expose only the required read operations.

The main design lesson is to keep authorization outside the model and treat prompts, approvals, and containers as supporting controls rather than security boundaries.

A restaurant manager agent can use one protocol to delegate an urgent order, another to read inventory, and others to structure checkout and verify payment authorization. The piece uses that flow to show where A2A fits alongside MCP, UCP, AP2, and existing web standards.

• A2A gives independent agents a shared contract for discovery, delegation, stateful tasks, progress updates, and artifacts without exposing their internal implementation.
• MCP covers tool and context access, while A2A handles collaboration between autonomous endpoints with their own execution logic.
• Extensions let domain protocols such as UCP and AP2 add commerce-specific data and authorization without expanding A2A’s core.

The architecture depends on clear protocol boundaries, so each layer can specialize while remaining composable with the others.