Moving the model closer to the data
2.6 billion parameters are enough for an agent that lives on the device
Liquid AI released LFM2.5-2.6B and its base checkpoint. The model is intended for
more than short chat: its post-training covers tool use, web search, software
engineering, and work inside real agent harnesses. It has a claimed 128K context
and a training corpus of roughly 34 trillion tokens.
Liquid reports 220 tok/s on an M5 Max, 113 tok/s on a Ryzen AI Max+ 395, and
around 30 tok/s on a phone while using less than 2.5 GB of memory. At high
concurrency on an H100, the vendor benchmark reaches nearly 15,000 output tok/s.
Those figures do not transfer to arbitrary devices or workloads, but the product
class is already visible.
A local agent pays no API fee per token, can respond with low latency, and does
not have to send source data to a cloud service. In return, the operator pays
for hardware, energy, updates, telemetry, and tool security. “Free inference”
removes the provider's meter, not the operational cost.
The new mode is particularly interesting: many small background agents that
continuously sort, inspect, and observe at the edge. One mistake is cheap, but
the aggregate number of actions is enormous. Locality therefore improves
privacy while increasing the need for capability accounting.
Concepts: edge inference, agentic RL, local privacy, marginal cost,
capability accounting.
Source: Liquid AI announcement.
Web search returned to the cloud as a governed internal tool
Amazon Bedrock made Web Search generally available for GPT-5.4, GPT-5.5, and the
GPT-5.6 family. Search runs server-side inside AWS against Amazon's own index and
knowledge graph, while one API call returns a grounded response with citations.
For an enterprise buyer, this is less a new search capability than a reduction
in trust boundaries. There is no separate search provider to onboard, second API
key to distribute, additional orchestration to build, or extra vendor review to
complete. AWS promises zero data egress from the secured AWS environment.
That phrase does not mean there is no external data. The model still receives
fragments of the open web; one provider now controls the index, extraction, and
delivery. Prompt injection, poor sources, and stale pages do not disappear when
the network boundary gets shorter.
Search as a built-in tool simplifies policy: one IAM model, one audit surface,
one data-residency story. The other half still matters — retaining citations,
constraining domains, and distinguishing retrieved text from instructions to the
agent.
Concepts: server-side tool, data residency, web grounding, citation,
trust domain.
Sources: AWS announcement,
Bedrock documentation.
A database agent gains the entire lifecycle — and the entire blast radius
Google described two specialized database agents. The Onboarding Agent helps
move schemas and workloads. The Observability Agent correlates telemetry,
configuration, and known failure patterns for operation after launch.
The interface is not confined to one chat: Cloud Console, CLI, IDE, and MCP all
provide access to the same operational layer from different working contexts.
That is a natural evolution. Diagnosing a database requires more than SQL; it
requires metrics, logs, configuration changes, and event history.
But that completeness creates the risk. An agent that understands a failure is
easily tempted to fix it immediately. Diagnosis and mutation need separate
permissions, a change plan, approval, rollback, and post-change verification.
Without them, a smart observability tool becomes a privileged operator capable
of making a very fast mistake against production data.
Concepts: day-0, day-2 operations, telemetry correlation,
change approval, rollback.
Source: Google Cloud on database agents.