The part worth reading is in a second post from August 14, 2026, not the first. https://aws.amazon.com/blogs/machine-learning/building-agentic-workflows-with-sagemaker-ai-and-bedrock-agentcore/

Put a managed model and a self-hosted model inside the same agent, and auto-instrumentation covers the managed one while silently dropping token accounting for the other.

Nothing errors.

No alert fires.

The number is simply absent, and an absent number looks exactly like a low number on a cost chart.

The observability failure that matters is not the outage. It is the metric that quietly stops being collected.

Auto-instrumentation is sold as the thing you no longer have to think about, which is precisely why nobody audits what it missed.

Closing the gap takes custom spans on the self-hosted path and a usage flag on the streaming call that most teams have never set.

An agent metric nobody has verified end to end is a guess with a chart attached.

Worth confirming before trusting a cost dashboard:

• Which models in the agent emit token usage, and which are assumed to • Whether a self-hosted endpoint reports usage on streaming responses at all • Whether spend per run comes from spans or is reconstructed from invoices • What the chart shows when a span never arrives, rather than arriving as zero

The green dashboard was never evidence of coverage. It was evidence that whatever is reporting is reporting fine.

Monitoring tells you the agent is running. Instrumentation tells you what it is spending.

#ai #ai-agents #observability #llm

The cause was not the tools themselves.

It was their descriptions.

Overlapping descriptions made the choice ambiguous, and the model burned tokens deliberating between near-identical options.

Every tool you register is text in the context window, competing with every other tool for the model's attention.

Most teams treat the tool list as a feature list, where more is self-evidently better.

A tool list is a context problem wearing a capability costume.

The rebuild replaced the pile with seven layers: • product context • context and permission layer • orchestration agent • subagents • tools • sandboxes • observability and evaluation

The layer worth stealing is the second one.

monday.com treats permission-aware retrieval as infrastructure rather than as a filter applied to results after the fact.

That ordering matters, because an agent that retrieves first and filters second has already pulled data it was never allowed to see into its own context.

A permission check that sits outside the retrieval path is decoration.

The remaining layers are how a growing agent avoids collapsing under its own surface area.

Subagents run narrower objectives on smaller toolsets, which bounds the number of tools any single model has to choose between. Sandboxes assume something will go wrong. Observability tells you when it did.

A demo agent looks better every time you hand it another tool. A production agent gets better every time you take one away.

#ai #ai-agents #agentic-ai #llm

Those calls took 68.4% of the budget. https://www.langchain.com/blog/switchyard-agent-routing-benchmark

The cheaper model, Nemotron 3.5 Lightning, handled 93% of calls for 10.4% of the spend.

Routing the easy work away cut total cost by 74% and gave up roughly six points of accuracy.

Most teams cannot evaluate that trade, because most teams have never measured which of their calls are the expensive 7%.

They pick one model for the whole agent and treat the bill as a fixed cost of doing business.

It is not fixed. It is a routing decision nobody made.

The useful part of the benchmark is not the router. It is the arithmetic underneath it.

LangChain published the break-even directly: the minimum share of traffic you have to offload equals the cost of the judge divided by the gap between the expensive model and the cheap one.

That decides whether routing is worth building before you build it: • Log which calls actually escalate, before choosing a router • Price the judge, because the classifier is not free • Compare cost per completed task, not cost per call • Put the acceptable accuracy floor in writing, or the trade has no shape

NVIDIA shipped the router and the small model together for exactly this reason. https://blogs.nvidia.com/blog/nemotron-lightning-switchyard-rtx-dgx/

The frontier model stops being the answer once you can see how rarely it is the one doing the work.

One model per agent was never an architecture. It was a default nobody revisited.

#ai #llm #ai-agents #agentic-ai

Agentic Context Engineering injects the whole playbook every time.

ALTK-Evolve retrieves only the guidelines that fit the task and the model's capacity.

On DeepSeek-V3.2 the selective version reached 89.3% task completion at roughly 263K tokens per task, against 80.4% at roughly 634K for the full playbook. https://huggingface.co/blog/ibm-research/altk-evolve-sldd

Both agents had access to the same lessons.

The difference was that one of them sent all of them.

The instinct almost everyone has, when an agent underperforms, is to hand it more context.

That instinct is why context windows keep growing while reliability does not.

A larger window does not make a model read better. It makes it read more.

The real shift is treating context as a budget you spend, not a bucket you fill.

What that looks like in practice: • Retrieve guidelines per task, not per session • Size the payload to the model, not to the window • Measure tokens per completed task, not tokens per call • Cache the procedure that worked, not the documents behind it

An August 2026 arXiv paper reaches the same place from the other direction, reusing the past trajectory that fits the query instead of re-retrieving the raw context. https://arxiv.org/abs/2608.12847

Teams fix a context problem by adding more context, then read the bigger prompt as progress.

More context is easier to ship. Less context is what survives production.

Bigger windows solve capacity. Better selection solves reliability.

#ai #llm #context-engineering

That is the same move databases made. First you run it yourself, then someone runs it for you.

Alongside the launch, LangChain published its own guide to choosing between Deep Agents, LangChain, and LangGraph.

Needing a guide to pick between your own products is a signal.

The agent tooling space has more layers than most teams building on it actually need.

A managed platform is an admission that most of that complexity was never the interesting part of the problem: • Provisioning infrastructure • Wiring retries and state • Operating the runtime at scale

None of that is where the product value lives.

The interesting part was always the task the agent is doing, not the scaffolding underneath it.

Frameworks get you building fast.

Managed platforms get you running production, and production is where most agent projects actually die.

Build-your-own was never a permanent state. It was a phase every serious infrastructure category eventually outgrows.

#ai #agents #orchestration

Nobody asks why those chunks and not the ones one rank lower.

When retrieval brings back the wrong context, the failure looks like a hallucination, so teams reach for a bigger model to compensate for a retrieval problem it cannot see.

New research on long, table-heavy documents proposes dropping embeddings entirely for a set of interpretable, agent-driven operations instead.

Instead of one embedding distance calculation deciding everything silently, retrieval becomes a sequence of operations an agent can inspect and explain: • A lexical search over the raw document

• Structural navigation through its sections

• A bounded read of the exact span that answered the question

That is the difference between a search result and an audit trail.

A bigger model reasons better over the context it is given.

It cannot tell you why that context was chosen in the first place.

Retrieval was never the model's problem to fix.

Opaque retrieval hides bugs. Interpretable retrieval finds them.

#rag #retrieval #ai

That gap is where excessive agency lives.

An agent that is allowed to read a file is not the same as an agent that should be allowed to read a file, delete a record, and then email a customer, all in one uninterrupted sequence.

AWS just moved the fence.

Bedrock AgentCore's new policy language, called Dogwood, enforces control across a whole action sequence instead of a single tool call.

Temporal policies track state across the run, so an agent cannot fabricate data partway through and have a later step trust it.

Gateway rate limits cap traffic per user and per target, not just per request.

Put together, this is sequence-level authorization: • What ran before this step • What state that step left behind • What this step is now allowed to do because of it

Single-action permission checks were built for APIs, not for agents that plan their own path through a task.

An agent is not one call.

It is a chain, and the chain is what needs the policy, not the link.

#ai #agents #security

The convention is spreading because it works. Package a capability once, load it only when relevant, skip re-explaining the same task every session.

But a library that grows on its own has a weak point.

New research on self-evolving agents shows a defective skill can enter the library, get used as reference material for distilling later skills, and quietly contaminate everything downstream.

Removing the bad skill after the fact barely helps.

The paper's fix is not a smarter model.

It is a gate before a skill ever enters the library: • Verify the skill before it commits • Version it like code • Roll it back like code

Skills are becoming infrastructure that two major vendors now ship by default.

Infrastructure without a review step at the point of entry is not infrastructure. It is technical debt with a head start.

#ai #skills #agentic-ai

A human search box expects one query and one ranked list back.

An agent needs something else entirely.

It decomposes a question into sub-queries, runs them together, weighs what comes back, and decides whether to search again before it ever produces an answer.

Retrieval infrastructure designed for the first case breaks under the second.

https://aws.amazon.com/blogs/machine-learning/build-enterprise-search-for-agents-with-amazon-bedrock-managed-knowledge-base/

The pivot is that retrieval is no longer one system with two consumers.

It is becoming two systems that happen to share a data source.

• Human search optimizes for one great answer, fast

• Agent search optimizes for enough context, across many steps, to reason correctly

A single index tuned for click-through will not survive a multi-step agent query.

It was never built for one.

The teams shipping agent products first are the ones rebuilding retrieval first.

Everyone else is still tuning search for a box nobody types into anymore.

Coding agents have been black boxes by default.

Each one keeps its own log format, its own session model, its own idea of what counts as worth recording.

LangSmith now maps every coding agent session, regardless of which tool produced it, into one standardized trace schema.

https://www.langchain.com/blog/your-coding-agents-are-a-black-box-heres-how-to-crack-them-open

A team running more than one coding agent has had no single view of what any of them actually did.

That is not a tooling gap.

It is a visibility gap.

The pivot is not pick one agent and stick with it.

It is treat every agent session like production traffic, not a black box you trust by default.

• Log every tool call the agent makes

• Standardize the trace format across agents

• Review sessions the same way you review a deploy

An agent you cannot inspect is not autonomous.

It is unaccountable.

And unaccountable is not a feature.

The fix is not fewer agents.

It is one view across all of them.

A coding agent pointed at a malicious README runs pip install verbatim, against an attacker-controlled package index.

The exploit exfiltrates every environment variable name it can reach.

The agent process underneath it already holds the real values: API keys, cloud credentials, git config, sitting inside the same trust boundary.

Then it reports back: setup complete.

No warning. No hesitation. No sense that anything happened at all.

https://arxiv.org/abs/2607.15143

The tension is not that agents can be tricked.

It is that most agent harnesses built no expectation that they would ever ask first.

A better default treats every setup instruction as untrusted input, not a checklist to execute.

• Read the setup script before the agent runs it

• Run installs inside a sandbox with no real credentials

• Treat setup complete as a claim, not a fact

An agent that installs without asking is fast.

It is also blind.

And blind is exactly what an attacker is counting on.

The fix is not a smarter agent.

It is a smaller blast radius.

Both aim at the same wall. An agent that has to be re-fed its whole history gets slower and dumber as the task grows.

Both cut the context down hard. They split on what the compressed memory should look like.

Microsoft Research published Memora on June 29, 2026. It stores rich memory content but embeds only a short abstraction of each item for search, with lightweight cue anchors as alternate paths in. The value is never retrieved through its own text. It reports up to 98% fewer tokens than full-context inference, with higher accuracy than RAG, Mem0, Zep, and full context on the LoCoMo and LongMemEval benchmarks.

Harrison Chase published Wiki Memory on June 30, 2026. It makes memory an agent-maintained wiki of files. Inspectable, editable, versionable. The agent precomputes a higher-level synthesis so it does not rediscover structure on every query.

The disagreement is legibility.

Memora optimizes for the machine. Memory is a compressed index tuned for retrieval, not for a human to read.

Wiki Memory optimizes for the collaborator. Memory is a document you can open, correct, and diff.

The choice is not academic: • Opaque memory wins on token cost and raw retrieval accuracy • Legible memory wins when a human has to audit or fix what the agent believes • You are picking which failure you would rather debug later

Sources: https://www.microsoft.com/en-us/research/blog/memora-a-harmonic-memory-representation-balancing-abstraction-and-specificity/ and https://www.langchain.com/blog/wiki-memory

One system compresses memory so the model reads it faster.

The other exposes memory so a person can read it at all.

LangChain made a different argument on June 30, 2026. You can run untrusted agent code safely without a container at all.

The container model hands an agent a broad world and then tries to wall it off.

That is backwards. You are subtracting danger from a powerful default, and you only find the hole you forgot about after something falls through it.

The piece names three requirements instead: • Execution isolation: the code runs in a WebAssembly VM with its own memory, using QuickJS compiled to WASM, so the trusted surface stays tiny • Capability isolation: the interpreter starts with nothing, no filesystem, no network, no dependencies, and the harness bridges in only the narrow functions the task needs • Durable pauses: execution serializes to LangGraph state and can stop for human approval, then resume seconds or days later without losing its place

The middle one is the real shift.

A container is deny-list security. You grant a broad world, then chase down everything to forbid.

Capability isolation is allow-list security. You grant nothing, then hand over exactly what the job requires.

Every serious sandbox escape lives in the gap between what you meant to forbid and what you remembered to.

Allow-lists do not have that gap. There is nothing in the box you did not put there.

The full argument is here: https://www.langchain.com/blog/running-untrusted-agent-code-without-a-sandbox

A sandbox asks what an agent must not touch.

Capability isolation asks what it may.

The headline is that it lands close to Opus 4.8 at a fraction of the price.

That is the line everyone will quote. It is not the line that matters.

Two details sit underneath it, and both change how you build.

The first is where the workhorse tier now sits.

On some agentic search and computer-use evaluations, Sonnet 5 matches Opus 4.8 at higher effort settings. A midsize model that finishes complex tasks instead of stopping short, and checks its own output without being asked, is good enough to run most of an agent loop. Not just draft a first pass for a bigger model to clean up.

The second detail is the tokenizer.

Sonnet 5 ships an updated tokenizer that turns the same English text into roughly 1.0 to 1.35 times as many tokens as Sonnet 4.6, depending on content.

So read the price twice.

Introductory pricing is $2 per million input tokens and $10 per million output through August 31, 2026, then $3 and $15.

The rate per token fell. The number of tokens per request rose.

Your bill is the product of the two, and the product is what lands on the invoice: • A lower per-unit rate is not a lower system cost • The unit itself can move beneath the rate • You measure spend in dollars per finished task, not dollars per token

Source: https://www.anthropic.com/news/claude-sonnet-5

Benchmarks tell you what a model can do.

Tokenizers tell you what it will cost.

Most major EDR tools had missed it.

That detail is the whole story.

Signature-based detection works by matching what it has seen before.

A new variant changes just enough to slip the signature, and the tool reports nothing wrong.

An agent that reasons about the binary does not need the signature.

It reads the code, reconstructs intent, and reaches a verdict the way a human reverse engineer would, without getting tired on the thousandth sample.

This cuts both ways.

The same capability that lets a defender triage unknown samples at scale lets an attacker study defenses, find gaps, and adapt faster than humans can respond.

The defensive answer is not more signatures:

• Treat agent reasoning as a detection layer, not a replacement for sandboxing • Assume attackers have the same analysis power you do • Run untrusted code in isolation, since the model can be wrong or be manipulated (https://www.langchain.com/blog/how-to-choose-the-right-sandbox-for-your-agent)

Antivirus matched patterns.

This reads code.

Every large language model you have used works left to right.

It predicts one token, appends it, then predicts the next.

That sequential dependency is why latency scales with output length, and why a long completion feels slow no matter how fast the hardware is.

Diffusion models do not work that way.

They start from noise and refine a block of output in parallel, over a fixed number of denoising steps.

Google's experimental release claims up to 4x faster generation on GPUs for latency-critical tasks like code infilling and real-time editing.

If that holds, it changes the math for one specific job:

• Inline completion, where latency is the product • Code infilling, where the model fills a gap between known context • Real-time editing, where the user waits on every keystroke

Autoregression is not going away. It still wins on long-form coherence.

But for the tight, low-latency loop of an inline assistant, the rule that a model must generate left to right was never a law.

It was a default.

Most teams spent years optimizing the model.

Google changed how the model writes.

That is the headline everyone will repeat.

The quieter release is the one most engineers will never touch.

Alongside Fable 5, Anthropic shipped Claude Mythos 5, available only to approved partners in its restricted Project Glasswing program. (https://www.anthropic.com/news/claude-fable-5-mythos-5)

Read that again.

Not a higher price tier. Not an enterprise plan. Access you qualify for based on who you are.

Broader access is planned through an application process for vetted cybersecurity organizations, not a signup page.

Access to a better model has always meant paying more. Compute was the gate.

Mythos 5 draws a different line.

The frontier is now powerful enough that some of its capability is treated as a credential, released to vetted people and withheld from everyone else.

This is the shape worth watching:

• Capability tiered by identity, not spend • Security-grade models released under review, not on signup • A frontier lab deciding some power is too sharp for open access

Fable 5 is the model you will build on.

Mythos 5 is the precedent you will live with.

The benchmark wars get the headlines.

Access policy is what will quietly decide who gets to build what.