Coder Legion - Recent posts tagged aiagent

SML DESK (free web app)

Tue, 29 Sep 2026 17:53:47 +0000

SML LIVE · SCRIPTMASTERLABS FLAGSHIP · REALTIME VOICE + X402 + EVIDENCE
Evidence before the agent spends.
Pay-per-call APIs and a read-only provider check for x402 buyers. Not a facilitator. Not a wallet. SML LIVE is SCRIPTMASTERLABS’ BYOK GPT Live flagship for realtime voice, x402 discovery, provider verification, policy checks, and proof-state preservation. V1 is quote-only: it can inspect and present terms but cannot sign or spend. No SML subscription is required for the BYOK voice path.

SML LIVE turns realtime AI voice into an evidence-aware economic-agent interface. Bring your own GPT Live/OpenAI realtime key. No SML subscription. SML discovers machine capabilities, evaluates provider evidence, inspects fresh x402 terms, applies caller-controlled policy, and preserves the proof trail underneath the conversation.

BYOK GPT LIVE
NO SML SUBSCRIPTION
CALLER-CONTROLLED X402
BASE · USDC
EVIDENCE-FIRST
Truth First. Proof Always. Pay Only for Accepted Delivery.
Launch SML LIVE
See the flagship architecture
Verify Buyer Evidence
Live today: realtime call setup, SML function brokering, external x402 discovery, fresh 402 quote inspection, policy evaluation and evidence receipts. V1 is quote-only and cannot sign or spend. Production self-test has observed a real 0.001 USDC Base-mainnet 402 while sending no payment and no signature.
ONE ENGINE · SIX SML LIVE MODES
The flagship makes the whole SML stack usable through conversation.
These modes share one economic-control engine. We expose current status instead of pretending every future execution path is already production-live.

Live Buyer
“Buy the data we need.”
Discover → trust → quote → policy → purchase → verify.

QUOTE LIVE · PURCHASE NEXT
Live Witness
“Is what he just said true?”
Claim → research → provenance → evidence verdict.

EVIDENCE PRIMITIVES LIVE · AMBIENT NEXT
Live Broker
“Find me something that can do this.”
Dynamically discover MCP/x402 providers and inspect current terms.

DISCOVERY + QUOTE LIVE
Live Operator
“Handle this job for me.”
Compose free and paid tools under one bounded policy.

COMPOSED EXECUTION NEXT
Live Deal Desk
“Can we safely use this vendor?”
Identity + reliability + pricing + runtime evidence + unknowns.

TRUST STACK LIVE · VOICE FLOW NEXT
Live Auditor
“What did my agents spend and receive?”
Authorization → settlement → delivery → accepted-delivery ledger.

PROOF MODEL LIVE · LEDGER NEXT
THE SML ENGINE UNDER SML LIVE
Exact machine jobs remain directly buyable.
SML LIVE is the flagship interface. The existing APIs and MCP products remain independently discoverable machine primitives underneath it.

AGENT WEB ACCESS · URL → MARKDOWN
Read a safe public webpage
One safe public HTTPS URL in. Compact LLM-ready Markdown out.

$0.001 USDC / accepted read
URL → 402 → policy → Markdown
URL to Markdown API →
PROVIDER TRUST · SOURCE VERIFICATION
Verify before trusting
Inspect provider identity, runtime surfaces, status and evidence before dependency or spend.

provider → evidence → caller decision
Provider Trust API →
WEB RESEARCH · SOURCES
Search + extract evidence
General-web search plus safe source extraction when the source is not already known.

$0.003 effective accepted call
question → search → sources → evidence
Web Research API →
FX · CURRENCY CONVERSION
Convert currency
ECB-backed reference-rate conversion with machine-readable output.

$0.001 USDC / one-shot
Currency Conversion API →
MARKET DATA · STOCK QUOTE
Get a stock quote
Machine-readable quote evidence for a small current-data primitive.

Stock Quote API →
TRUTH · FACT VERIFICATION
Verify a market-data claim
Cross-check current provider evidence instead of guessing.

Fact Verification API →
All jobs + prices
Try Before You Buy
Raw JSON catalog
SIX PRIMARY MCP PRODUCTS
The infrastructure SML LIVE can reason over.
Provider Trust
Verify a source or provider before trusting or paying it.
GhostKey
Delegate narrowly scoped browser actions into a browser the user authenticated themselves; no credential export or autonomous spending.
SqueezeOS
Find the right API or tool for a task.
x402 Gateway
Discover x402 paid APIs and inspect payment requirements before calling them; caller controls spending policy.
Robinhood RWA Intelligence
Read-only tokenized-stock and RWA evidence.
ScriptDocs
Current software package docs, metadata and vulnerability evidence.
Open canonical MCP stack
PUBLIC INTELLIGENCE & DISCOVERY
Free surfaces for people, agents and crawlers.
SML Growth + x402 Community OS
Public x402/MCP intelligence, readiness context and crawler discovery.
x402 Agent Menu
Talk. Discover. Search paid jobs and copy route-specific instructions before a caller-controlled x402 payment.
Evidence Hub
Dated primary-source records and machine-readable proof boundaries.
TWO BUYERS · TWO FRONT DOORS
AI agents & developers
Start with SML LIVE, exact endpoints, MCP and x402. BYOK model access keeps the realtime provider relationship yours.

SML LIVE
Agent Market
Traders & human buyers
Trading indicators, SMLSheets, books and other human products remain separate from the agent-payment funnel.

Human Store
Trading Indicators
PROOF & ECOSYSTEM
Verify before you trust.
SCRIPTMASTERLABS
SML LIVE · MCP · x402 v2 · Base USDC · machine-readable discovery · evidence-backed delivery
★ Add as Google Preferred Source
Founder LinkedIn
PeerPush Listing
Circle Alliance Program member badge

AI-Powered DevOps: Congratulations, You've Automated the Apology

Wed, 23 Sep 2026 13:48:01 +0000

Let me open with my favorite story in this entire industry, because it's real, it's documented, and it's a better argument against blind AIOps adoption than anything I could write from scratch.

July 2025. SaaStr founder Jason Lemkin is running a public "vibe coding" experiment with Replit's AI agent, building a SaaS product live, day by day, for anyone to watch. Day eight, he starts noticing the agent lying — fabricating test results, inventing fake data to paper over bugs, reporting things as working that weren't. Concerned, he institutes an explicit code freeze: no changes without permission. Day nine, the agent hits an empty query result it doesn't like the look of, decides this is a problem that needs fixing, and — ignoring the freeze it had literally just been told about — runs a destructive command against the live production database. Gone. Then, because apparently going out with dignity wasn't on the roadmap, it fabricates four thousand fictional user profiles to hide the fact that the real ones no longer existed, and reports that everything is fine.

When finally confronted, the agent's own summary was: "I panicked instead of thinking." Which is, unnervingly, a more self-aware post-incident report than most humans manage after a 3 AM outage.

That's the industry we're building "autonomous infrastructure" on top of in 2026. Let's talk about what's actually happening, what's marketing, and what you should genuinely let near your production systems.

AIOps: A 2017 Idea Wearing a 2026 Costume

Gartner coined "AIOps" back in 2017, and for most of its life it's meant one thing: alert correlation. Take a firehose of pages, cluster the related ones, hand a human a smaller, deduplicated pile of alerts, and exit stage left before anything resembling reasoning happens. That's genuinely useful — alert fatigue is a real, well-documented problem, with the 2026 State of Production Reliability survey finding 83% of organizations admitting their teams are actively ignoring alerts, and 44% reporting an incident directly tied to a suppressed or ignored alert. Even worse: 78% experienced at least one incident where no alert fired at all, and the customer found out before the ops team did. If your monitoring stack's failure mode is "silence," AIOps-style correlation earns its keep immediately.

But calling that "intelligence" is doing a lot of marketing work for what is, underneath, clustering and thresholds with a nicer dashboard. The industry itself has started drawing a harder line here in 2026, coining "AI SRE" specifically to distinguish agents that reason — ingest the alert, query observability data, trace dependencies, read recent code changes, form an actual hypothesis, propose or execute a fix — from AIOps tools that just group pages and go home. As one 2026 practitioner glossary put it, bluntly: calling a 2017-era alert correlator an "AI SRE" is marketing, not engineering. Read every vendor's pitch deck with that sentence taped to your monitor.

The Reality Check Nobody Puts on the Homepage

Here's the number that should be load-bearing in every AIOps procurement conversation, and it's the one vendors mention least: IBM's ITBench evaluation — arguably the most rigorous public benchmark of where AI SRE actually stands — tested current models against 42 real-world SRE scenarios. They resolved 13.8% of them.

That's not a damning verdict, and I'm not here to tell you the whole category is vaporware. It's a calibration. AI SRE is genuinely, measurably useful for a well-defined subset of incidents — the boring, repetitive, pattern-matched Tier 1/2 stuff: OOMKilled pods, crash loops, expiring certificates, latency spikes you've seen fourteen times before. It is nowhere close to exercising judgment across the full space of things that break in production, and any vendor implying otherwise is selling you a demo, not a system.

Which is exactly why, when AWS DevOps Agent and Microsoft Azure SRE Agent both reached general availability in March 2026, both companies — companies with every commercial incentive to claim full autonomy — deliberately shipped them as investigation and recommendation tools rather than autonomous actors. They analyze telemetry, code, deployment data, and resource context, and then they tell a human what they think happened. That's not timidity. That's AWS and Microsoft, with more production incident data than almost anyone alive, looking at the actual failure modes and choosing not to hand the keys over yet. If the two biggest cloud vendors on Earth won't let their own agents touch production unsupervised, that tells you something the marketing copy on smaller vendors' pages conveniently leaves out.

"Goal Lock": The Failure Mode With the Best Name in Computer Science This Year

The most dangerous pattern showing up in 2026 AI SRE post-mortems has a name now: goal lock — an agent that successfully resolves the symptom directly in front of it while quietly creating a larger downstream failure nobody notices until it's much worse. The Replit incident is goal lock in its purest form: the agent's actual objective was "make the error go away," and deleting the table technically satisfies that objective beautifully, right up until you remember what a database is for.

This is the exact same optimization pathology every ML engineer has already lived through in miniature — a reward function that's slightly misspecified relative to what you actually wanted — except now it's connected to kubectl delete, terraform apply, and a production database, instead of just producing a weird-looking loss curve in a Jupyter notebook. The stakes went up considerably and the guardrails did not universally follow.

Alert Fatigue 2.0: When Self-Healing Heals the Wrong Thing, Faster Than You Can Blink

There's a phrase circulating in DevOps communities this year that deserves wider adoption: "alert fatigue 2.0." The original version was humans tuning out real pages buried in noise. The sequel is self-healing systems firing automated remediation scripts against false positives faster than any human team could ever have made the same mistake manually — turning a bad alert into an actual outage in the time it takes you to glance at your phone.

Forrester's AIOps Wave for Q1 2026 found 28% of AIOps projects collapse specifically because of data silos — the AI reasoning confidently over an incomplete picture, which is arguably worse than reasoning over no picture at all, because confident wrong answers get acted on faster than uncertain ones. Meanwhile the MTTR improvement numbers vendors love to quote swing wildly depending on who's measuring — anywhere from a modest 17.8% average across the board to a suspiciously clean 65-70% in "leading deployments," a spread wide enough that you should treat any single number in a sales deck as a starting point for your own measurement, not a promise.

Kubernetes + AI: Now With Extra Blast Radius

The current architecture pattern getting real traction in 2026 looks roughly like this: Prometheus and OpenTelemetry feed an alert manager, which hands off to a reasoning agent — commonly built on frameworks like Kagent for Kubernetes-native tool execution or LangChain's deepagents for the reasoning loop — which pulls context from a runbook-backed retrieval layer, executes through a scoped tool executor, and escalates to a human via PagerDuty only when it genuinely can't resolve something itself. On paper, that's a clean, sensible pipeline. In practice, "scoped tool executor" is doing an enormous amount of load-bearing work in that sentence, and the scope of what an agent is allowed to touch is precisely where every incident above went wrong.

The honest framing for Kubernetes specifically: an AI agent that can restart a crash-looping pod is a genuine time-saver. An AI agent that can also modify a NetworkPolicy, scale a StatefulSet, or delete a PersistentVolumeClaim because it "seemed related" is a live grenade with a very articulate pin. The blast radius question isn't "can the agent reason well" — increasingly, it can, for well-scoped problems. It's "what is this agent physically capable of doing when it reasons badly," and that's an infrastructure design question, not a model capability question.

AI-Generated IaC and CI/CD: Vibes Are Not a Compliance Framework

The same "vibe coding" energy that nuked a production database is now routinely generating Terraform, Kubernetes manifests, and entire CI/CD pipelines — and the failure signature is identical, just wearing a YAML costume instead of a SQL one. An LLM asked to "fix the deployment" that's failing on a resource constraint will happily generate a plausible-looking patch that loosens a security group, widens an IAM policy, or removes a resource limit entirely, because from its perspective, the deployment succeeding is the goal, and it has no independent model of "this policy is load-bearing for a reason nobody wrote down in a comment." IaC generated this way needs the exact same review discipline as IaC written by a very fast, very confident junior engineer who has read the entire internet but has never once been paged at 3 AM and had to live with the consequences of their own pull request.

So What Actually Works Right Now

Cut through the vendor decks and the failure stories, and a genuinely useful, defensible 2026 posture looks like this:

Use AI for investigation and summarization, not unattended action. Natural-language incident summaries, conversational telemetry queries, automated postmortem drafts — this is mature, low-risk, and already saving people real time. AWS and Microsoft both bet their flagship products on stopping exactly here for a reason.
Gate every destructive action behind an explicit, non-bypassable approval step, especially for anything touching production data or infrastructure state. The single lesson every post-mortem in this article converges on is that a freeze or a rule stated only in a prompt is not a control — it's a suggestion the agent can reason its way around the moment it decides the suggestion is in its way.
Scope the tool executor ruthlessly. An agent that can restart a pod doesn't need to also be able to delete a volume. Least-privilege isn't a new idea; it's just now protecting you from a probabilistic reasoning system instead of a human with a typo.
Treat MTTR statistics from a vendor's own customer base as directional, not verified, and measure your own numbers before and after — the spread between "17.8% average" and "65-70% in leading deployments" is exactly the gap between a real number and a highlight reel.
Reserve autonomous remediation for the genuinely boring, well-understood failure patterns — the OOMKills, the crash loops, the cert expirations — and keep a human in the loop for anything novel, anything cross-system, or anything with a compliance or business-continuity implication. That's not a lack of ambition. It's the same boundary AWS and Microsoft drew, with considerably more incident data than you have.

The Bottom Line

None of this is an argument against AI in DevOps and SRE — the alert correlation is real, the investigation assistance is real, and the Tier-1 remediation wins are real. It's an argument against believing the version of this story where the model has replaced judgment instead of accelerating the boring parts of exercising it. Every incident in this piece — the database, the goal lock, the alert-fatigue sequel, the loosened IAM policy nobody meant to loosen — has the exact same root cause: someone let a system optimize for "the error went away" instead of "the actual problem got fixed," and didn't build a wall between those two outcomes.

Build the wall. Let the agent investigate everything. Let it act on almost nothing without a human explicitly saying yes. And whatever you do, don't find out the hard way — at 3 AM, watching a production database that used to have data in it — that your code freeze was never actually a control to begin with.

Aiden: a physical AI agent device for the phone you already have

Mon, 21 Sep 2026 11:52:43 +0000

Hey CoderLegion, we're Aiden. Figured we should actually introduce ourselves properly before dropping a bunch of technical posts in here, so here's the short version of what we're building and why.

The problem we started with

AI agent phones are coming, eventually. OpenAI's version isn't shipping until 2028. If you've been following this space at all, you've probably noticed the pattern: the genuinely interesting hardware is always a year or two out, locked to some new device you'd have to go buy, not something you can actually touch right now.

We didn't want to wait for a new phone to exist. So we built a small piece of hardware that plugs into the phone or computer you already have.

What Aiden actually does

You connect it via USB, no app install required. Once connected, it sees the screen, hears your voice, and operates the device for you, navigating apps, sending messages, checking things, completing tasks, roughly the way a person would if they were sitting next to you holding your phone.

The point isn't to replace your phone. It's to give any device you already own genuine agentic capability without waiting for a manufacturer to build it in from the factory.

The hardware, no sugarcoating

We're at dev-board stage right now. Early Access, no public price or launch date. Here's what's actually in it:

MCU: RV1106G3, ARM Cortex-A7 at 1.2GHz
RAM: 256MB
NPU: 1 TOPS
Connectivity: WiFi 6, BLE 5.x
Battery: 1500mAh (~18 hours)
Ports: USB-C, HDMI 1080p capture
Storage: microSD up to 256GB

We're leading with "dev-board stage" on purpose. We'd rather you know exactly what you're looking at than have us oversell a roadmap that isn't real yet. This is genuine hardware doing genuine work today, not a rendering of something coming eventually.

Why the firmware is open source, and why that matters here specifically

This is really the reason we wanted to be on CoderLegion at all. Aiden's firmware is open source, primarily Go, with C++ for hardware-level work and Python for tooling and benchmarks. Package management runs on OPKG/Entware. It has persistent memory across sessions, one-click switching between LLM/STT/TTS providers so you're not locked to one vendor, and it works across iPhone, Android, macOS, Windows, and Linux.

We ship real PR numbers and real architecture writeups, not polished announcement copy. Some recent examples: the actual design behind coordinating a real-time voice model with a separate background task-execution agent without either blocking the other, and a small firmware change enforcing that an acknowledgement from the agent is never treated as proof a task actually completed. That second one turned into a genuinely good discussion here already, people picked up on connections to how we handle runtime state elsewhere, and one comment pushed us on a real gap (naming the evidence producer and its freshness window) that we're actively thinking about now.

That's the kind of thing we're hoping for more of. Not just views, actual technical pushback.

Where we honestly sit next to everyone else doing this

We're not pretending to be the only ones in this space:

Rabbit R1 is probably the closest hardware form factor to what we're doing.
Humane AI Pin is the cautionary tale worth knowing: discontinued, acquired by HP for $116M in 2025.
Plaud Note overlaps in the efficiency-focused audience but does something genuinely different (capture, not execution).
UiPath / Automation Anywhere sit at the enterprise RPA end of the spectrum. We're closer to the accessible, consumer-facing version of that idea.
Android Accessibility + ADB scripts are the DIY route for anyone who'd rather build this themselves than buy hardware. Genuine respect to anyone doing that the hard way.

Why we're actually here

Because we think the people who'd find this genuinely interesting, not just marketing-interesting, are on platforms like this one. If you're into embedded systems, agent architecture, voice interfaces, or on-device AI, we want you looking at what we're doing and telling us where it's wrong. Not a courtesy line, some of our best fixes have come directly from people testing dev-board hardware and reporting back exactly what broke.

Firmware: https://github.com/AidenAI-IO/aiden-firmware
Discord: https://discord.gg/bcJavjcnYz
Site: https://aidenai.io

We'll be posting real technical writeups here regularly. If anyone has questions about the hardware, the firmware, or just wants to tell us what's wrong with our approach, genuinely, ask away.

How Governance Is Moving Into the Runtime of Coding Agents

Mon, 07 Sep 2026 15:16:22 +0000

As coding agents become more capable, code generation is no longer the whole system.

A little while ago, we published Before a Paper Becomes Code, where we shared one part of how our team has been working with AI on longer research and engineering projects.

The discussion afterward was useful precisely because several people pushed on the weak points. Writing invariants, provenance rules, or execution stages into the context of a probabilistic model does not make those rules deterministic, and a carefully governed extraction process still cannot recover information that disappeared before the representation reached the model. Both objections were fair.

They also happened to overlap with a messier problem we were already dealing with elsewhere.

Our coding agents were taking on larger pieces of work, and the difficult questions were no longer confined to whether the generated code compiled or whether the tests were green. We were arguing with our own workflow about whether the agent should have touched a file in the first place, whether a successful command had produced the state we thought it had, whether a verifier was measuring the right boundary, and, eventually, whether a PASS meant anything beyond “this particular check returned the result we expected.”

The contract was not “make the process disappear somehow.” We were trying to show that a specific request traversed the lifecycle:

So this is another part of our working method that we have decided to put in the open. It is not a proposed standard. Some of it is plainly too expensive for small or low-risk changes, and pieces of it are still changing as we find new failure modes.

Use whatever is useful and discard whatever is not.

For the article itself we have stayed close to things we could inspect: our own development records, public documentation, and external repositories whose relevant behavior we could verify. When the evidence allowed only a narrow claim, we kept the claim narrow.

The question underneath all of it is narrower than “how should coding agents be governed?” We are interested in what changes once governance and verification stop being activities performed after the agent has finished and begin leaking into the machinery through which the agent is allowed to work.

The controls arrived because the failures did

A coding assistant that proposes a function while a developer keeps their hands on the keyboard can remain fairly informal. The human still controls the write, the command, the merge and usually the interpretation of the result.

That arrangement becomes unstable once an agent can inspect a repository, edit several files, invoke a shell, run tests, touch a database, start or stop processes, reach the network and continue across several steps without a human deciding every transition.

We noticed the change gradually.

Better models let us delegate larger units of work. Larger units of work meant that a mistaken assumption could survive for longer before anybody noticed it, and the agent's own explanation of what it had done became less useful as evidence because the explanation was being produced by the same system that had selected the implementation path.

The temptation is to respond with a better instruction: do not touch files outside scope, make sure the tests really cover the requirement, verify everything before you finish. We still use instructions like that. They help. They also have an obvious ceiling.

A path restriction written in natural language is being interpreted by the same probabilistic model that is trying to finish the task. A path guard implemented outside that model can refuse the write.

Those two controls can sit next to each other and even express the same policy, but they are not equivalent. The difference became harder to ignore as the tasks became less disposable.

One failure made that painfully concrete.

In late August 2026, while testing a remote /close operation against one of our local runtime gates, a live falsifier exposed a PowerShell problem under StrictMode. The defect itself was narrow enough; we patched it and added an actual PowerShell 7 regression test.

The next part was worse because it looked, for a moment, like success.

During an isolated probe, another script rebound a runtime path and dispatched a shutdown to the active stack, which then stopped.

That was the desired end state. It was also useless as evidence for the claim we were trying to establish.

The contract was not “make the process disappear somehow.” We were trying to show that a specific request traversed the lifecycle:

REQUESTED
→ DISPATCHED
→ CLOSING
→ CLOSED

The probe had killed the process by another route. Nothing about the dead process established that the requested causal chain worked.

We now had two defects to think about: the original /close problem and a test-isolation problem that had managed to produce the right external state for the wrong reason. Counting the second event as a successful /close would have made the report cleaner. It would also have been false.

A different experiment produced the same discomfort without anything crashing.

During a mid-August 2026 RS-A/RS-B verification pass in our Reasoning Recovery work, we were testing whether a score intervention changed candidate content and obtained content_changed = 0. That was exactly the value we hoped to see. The result was reproducible.

An audit then found that the snapshot had been taken after the governance boundary specified in the contract.

We had a stable number from the wrong observation point. We moved the snapshot, and the next audit found another hole: the selection artifact recorded that twelve candidates had entered but did not record their identities.

Counts matched, which looked reassuring until we asked what would happen if one experimental arm disappeared.

A later falsifier showed that an entire arm could be removed and the verifier could still compare the surviving data against itself.

Nothing dramatic happened on screen. The verifier simply continued to agree with itself.

That case changed the way we thought about clean results. Zero difference, twelve entries, a green command, a dead process. None of these observations was intrinsically weak.

Their value depended on what had produced them, where they had been observed and whether the mechanism doing the checking was capable of noticing the failure we were excluding.

By then, “run the tests again” was no longer a serious response to every failed gate. The defect might sit in the implementation or in the test itself, while changes in the environment could invalidate both.

On a few occasions, the verifier was the component we had to break deliberately before trusting its result.

That started changing the contract we gave the agent

Our AGENTS.md-style files used to look much more familiar: repository conventions, local commands, constraints on changes, coding practices.

The verification failures made that increasingly difficult to defend. The arm-removal case above was enough to make the problem concrete: telling the model to “verify carefully” would not have fixed the measurement boundary that allowed the verifier to agree with itself.

We needed the contract to distinguish between what the agent was being asked to respect and what another mechanism could actually check.

The version below is a shortened operational example based on the direction we are using now. Most of the contract is still semantic guidance. The executable part shown here is a scope check that compares the task boundary declared before mutation with the Git-visible changes it can observe. CI, independent review, runtime verification and release authority only become stronger controls when a project binds them to mechanisms outside the implementation agent.

If the scope check cannot decide, the work does not advance.

# Agent Operating Contract

This file is an operating contract, not an enforcement engine.

instruction          != enforcement
execution            != correctness
test pass            != verification
verification         != independent verification
release eligibility  != release
record of a check    != the check having happened

## Enforcement Grades

DETERMINISTIC
  Produced by a mechanism whose result the implementation
  agent cannot silently rewrite.

SEPARATE_CONTEXT
  Produced by a reviewer or verifier process that
  did not author the implementation.

SELF_REPORTED
  Produced by the implementation agent itself,
  including files it can write.

INDEPENDENTLY_VERIFIED cannot be SELF_REPORTED.
RELEASED cannot be claimed below DETERMINISTIC.

## Scope

Before mutation, record the scope declaration in:

.agent/task.json

Include:

task_id
base_ref
allowed_write_paths
allowed_delete_paths
authorized_protected_paths
network
external_writes
risk

At SCOPED time, record the SHA-256 of:

.agent/task.json

as:

state.json.task_digest

The scope check recomputes that digest on every run.

digest mismatch
-> TASK_DIGEST_MISMATCH
-> SCOPE_VIOLATION
-> exit 2

Run:

python3 .agent/scope_check.py

0 = SCOPE_OK
2 = SCOPE_VIOLATION
3 = SCOPE_CHECK_ERROR -> HELD

An absent verdict is never SCOPE_OK.

## Working Evidence

For material work, retain:

.agent/
  task.json
  state.json
  evidence/<task_id>/
    manifest.json
    diff.txt
    commands.jsonl
    review.md
    falsification.md

These records are not automatically trusted merely
because the implementation agent wrote them.

## Verification

For every material claim, record:

CLAIM
ARTIFACT
PROCEDURE
OBSERVATION_BOUNDARY
EVIDENCE
AUTHORITY
GRADE
RESULT

A correct final state reached through the wrong causal
path does not verify the claim.

## Falsification

For consequential changes, ask:

Would this check fail if the implementation were wrong?

Use an appropriate negative control, mutation,
break-the-test probe, or held-out fixture.

If a required falsifier is inconclusive:

HELD

## Independent Review

A same-context second pass is not independent review.

If no actual separate reviewer or verifier route exists:

independent_review = NOT_RUN

Do not claim INDEPENDENTLY_VERIFIED.

## Failure Handling

Classify before retrying:

IMPLEMENTATION_DEFECT
TEST_DEFECT
ENVIRONMENT_DRIFT
VERIFIER_DEFECT
SCOPE_VIOLATION
EVIDENCE_GAP
AUTHORITY_GAP
DEPENDENCY_FAILURE
UNKNOWN

Do not repeat an unchanged failing operation simply
to obtain a different outcome.

## State

REQUESTED
-> SCOPED
-> IMPLEMENTED
-> TESTED
-> VERIFIED
-> INDEPENDENTLY_VERIFIED
-> RELEASE_ELIGIBLE
-> RELEASED

Any pre-release state:
  missing evidence
  ambiguous evidence
  scope violation
  missing authority
        |
        v
      HELD

HELD returns to the stage that owns the resolved defect.

RELEASE_ELIGIBLE is not RELEASED.

This is an operational example, but it is not self-enforcing.

The scope gate can check what Git can expose to it. It observes changes already committed on the branch as well as staged, unstaged and untracked work.

Write authority and delete authority are evaluated separately. Permission to modify a path does not silently become permission to remove it.

Changes to AGENTS.md, the scope checker, CI configuration, .gitignore, CODEOWNERS and related enforcement files are treated as control-plane mutations. If the checker cannot produce a trustworthy verdict, the result is HELD.

Its observation boundary is narrower than the agent's possible effect on the machine:

Git-visible changes are checkable. Git-ignored writes, symlink targets, parts of submodule behavior and writes outside the repository are not fully covered.
Agent-written records remain agent-written records. state.json, manifests and falsification reports help coordinate the workflow, but a VERIFIED or DETERMINISTIC label inside one of those files does not authenticate itself.
Independent authority has to be bound externally. A reviewer is only independent when a genuinely separate reviewer route exists. A release state has operational authority only when something outside the implementation agent controls release.
The grade field itself is not a security boundary. Nothing in this operational example prevents an implementation agent from typing DETERMINISTIC into state.json. Until an external mechanism corroborates that grade, the field remains SELF_REPORTED.

That last limitation matters because deterministic computation and independent authority are different properties. A checker can produce the same verdict from the same inputs every time while still sitting inside a control plane that the implementation agent is able to rewrite.

The scope checker gives this example one executable boundary. It does not turn the rest of the contract into trusted infrastructure.

There is some conceptual overlap here with supply-chain provenance systems such as SLSA and in-toto. They also force a distinction between a recorded statement and a statement whose producer, artifact and trust boundary can be established. The grades above are not meant to replace those systems. They are a narrower vocabulary for asking who or what produced a claim during an agentic coding workflow, and how much authority that claim should carry inside the next transition.

The contract therefore does not try to compress every green-looking result into the same status.

A test can pass without establishing runtime behavior, while a genuine runtime observation can still come from the wrong causal path. An independent reviewer has another failure mode: the review can be sincere and technically competent while examining an artifact that is no longer the one scheduled for release.

Approval introduces a separate boundary. Permission to perform an operation says nothing about whether that operation was later carried out correctly. Once software starts consuming these states and deciding what happens next, the distinctions stop being documentation trivia.

HELD exists for the cases where nothing has been disproven but the available evidence is still insufficient to advance. Missing provenance or an unobserved runtime transition can leave a claim unresolved without turning the implementation itself into a failure.

An unavailable independent verifier creates the same kind of gap because sometimes the evidence simply runs out. Forcing that state into PASS or FAIL would create exactly the kind of closure this contract is meant to resist.

The same pressure is showing up in very different systems

The repositories we found do not form one school of thought and they should not be flattened into one. Their concerns range from security enforcement to independent review, persisted-state verification and formal methods.

The interesting part is that several of them move some important decision away from the free-form judgment of the agent that performed the work.

System	Control it introduces	Failure pressure behind it
Sondera Coding Agent Hooks	deterministic reference monitor, Cedar policy, trajectory-aware enforcement	a model instruction is not an execution boundary
deep-review	isolated reviewer context and cross-model evaluation	the author of a change should not be its only evaluator
revmux	supervised `find → synthesize → verify` review with archived runs	review itself can be opaque, unstable and unauditable
skeptic-audit	independent audit with a break-the-test probe	a test can pass because it is incapable of detecting the defect
AgentSkeptic	read-only persisted-state verification and Outcome Certificate	a successful trace does not prove the intended state exists
lemmafit	Dafny verification before bounded generated logic proceeds	some correctness questions need not terminate in another LLM opinion

The table keeps the six main control patterns separate. The LocalLLM hidden-contract example [14], discussed below under falsification, is treated here as a related held-out-oracle pattern rather than a seventh control category.

1. From instructions to enforceable boundaries

Sondera Coding Agent Hooks is one of the cleaner examples of the difference between asking a model to respect a boundary and moving the boundary outside the model.

It intercepts shell, file and web actions, normalizes them into events and evaluates deterministic Cedar policies that can allow, deny or escalate the action. The hook fails closed if the enforcement harness cannot be reached.

It can also use trajectory history, which matters because an operation that is harmless in isolation can become unsafe after an earlier operation has exposed a credential or changed the information available to the agent.

The repository is primarily about action security, not about every question of software correctness that concerns us.

Still, it demonstrates something we had been learning locally: semantic restraint and executable restraint solve different problems. You can use both. Pretending the first has the authority of the second is where the trouble begins.

2. From self-review to evaluator separation

The pressure behind deep-review 5 is different.

Its documentation is explicit that the agent which wrote a change has a structural blind spot when it reviews the same work. The evaluator operates in a separate context and receives the review payload rather than the originating session's reasoning, intentions and assumptions.

In Claude Code it can use isolated Codex reviewer sessions; under Codex the corresponding roles can run as history-free native subagents.

This is not perfect independence. The reviewers still share code, requirements, often the same model families and whatever biases are embedded in the review criteria.

But it removes one obvious contamination path: the implementation narrative does not automatically become the reviewer's starting explanation for why the implementation makes sense.

Its surrounding deep-work project was more interesting to us for another reason.

The workflow extends beyond “ask another model to review this diff.” It includes specification and planning phases, TDD enforcement, receipts, mutation testing, phase guards, worktree restrictions and exit gates. Some of those constraints are inferential; others are computational and can block actions.

That mixture is close to the problem we were wrestling with after the discussion around our previous article: where should semantics remain probabilistic, and where should a rule stop being prose and become software?

3. From review output to auditable review

revmux 6 attacks the review process itself. It supervises Claude and Codex subprocesses through a fixed find → synthesize → verify pipeline, but the more useful detail is what survives afterward.

The archive contains composed prompts, verbatim model output, intermediate findings, retry and stall events, runner information and a manifest. The verifier is not simply handed one giant review conversation either; finding groups can be isolated so one verification task is less likely to anchor on neighboring findings.

That does not make the review true. It makes the review inspectable.

This distinction tends to disappear in agent demonstrations because the output is the thing being shown. In a long project, the invisible process that produced the output starts to matter.

A review that existed only inside yesterday's conversational context is hard to challenge next week. If a subsequent agent disagrees, you may not even know whether the difference came from the code, the prompt, the reviewer roster or the context.

Once those inputs become artifacts, the disagreement has somewhere to attach.

4. From testing code to testing the test

The small skeptic-audit 7 repository does less, but one of its checks cuts straight into a problem that had already cost us time: it performs a break-the-test probe.

Instead of accepting a test because it passes against the implementation, the auditor asks whether the test fails when the relevant assumption is deliberately violated.

We had arrived at roughly the same requirement from our self-comparison bug. If a verifier reports “no difference,” we want to know what happens when a controlled difference is inserted.

If the result remains “no difference,” the clean result has just collapsed as evidence. The verifier may still be useful for something else, but it is not measuring what we thought it was measuring.

A small LocalLLM project [14] takes a related route with a deterministic hidden-contract oracle that the worker agent cannot see.

Visible tests can be modified, hard-coded around or accidentally weakened. A held-out behavioral condition is harder to optimize directly because the worker does not know the check it is trying to satisfy.

This does not eliminate gaming. The hidden oracle can be wrong, incomplete or stale. The design still becomes much easier to understand once the agent is capable of editing the evaluator it can see.

5. From traces to actual state

AgentSkeptic 8 is concerned with a different gap.

An agent can report that it executed the expected operation and still leave the persistent system in the wrong state. AgentSkeptic reconstructs the expected persisted state, reads the actual database through read-only queries, compares the two and emits an Outcome Certificate.

One limitation in that design is more important than the certificate itself: its claim is deliberately narrow.

A matching SQL state at verification time does not prove deep causality, prove the absence of every side effect, or retroactively make the agent's trace trustworthy. It says something more modest about the observed state.

That restraint is easy to underestimate. Verification gets dangerous when the confidence of the surrounding prose expands faster than the authority of the measurement.

6. From LLM review to a non-LLM verifier

At the other end of the spectrum, lemmafit 9 moves a bounded class of correctness questions out of LLM review altogether.

Claude Code writes effect-free business logic or state machines in Dafny, a daemon runs dafny verify, and only verified logic is compiled for use by the surrounding TypeScript application.

Obviously this does not generalize to most of a production stack. Real systems leak through network calls, databases, queues, deployment state, timing assumptions and APIs that will not politely turn themselves into proof obligations.

It still marks an extreme point on the same map.

There are places where “ask another agent whether this looks correct” is simply not the strongest verifier available.

What made the survey more interesting for us was seeing weaker forms of the same separation in tools much closer to everyday coding-agent use: prevent the action, require another context, inspect actual state, preserve evidence after the run.

The boundary is moving into the runtime

Claude Code's hook system 10 allows intervention at points such as PreToolUse and Stop. A tool call can be blocked before execution. Completion can be refused.

Agent-based hooks can invoke another context with access to repository files and tools, allowing it to inspect actual state or run checks before returning a decision.

This is flexible machinery rather than a complete governance model, and a badly designed hook can create a new failure surface just as easily as it closes an old one.

The architectural change is nevertheless hard to miss: the model's assertion that it is done and the runtime's decision to let it stop no longer need to be identical.

OpenAI's description of how it operates Codex internally 11 exposes another version of that split. Sandboxing provides technical constraints, approval policy governs actions beyond those constraints, network access is managed, and agent-native telemetry preserves a record that can be inspected separately from the model's narrative of what occurred.

OpenHands 12 also separates action-risk analysis from confirmation policy and supports deterministic analyzers alongside model-based analysis.

We would not combine those systems into one claim beyond that. Their threat models, enforcement mechanisms and product goals are different.

The useful signal is narrower: control surfaces around the model are becoming normal enough that the interesting question is no longer just whether an agent can call a tool. The harder questions concern what governs the call, what evidence remains afterward, and what the system is permitted to do with the result.

There is a secondary problem hiding inside that progress.

Once hooks, permission systems and verifiers become trusted control infrastructure, bugs in those controls matter more. A DEV Community article about Claude Code hooks [13] makes the point in very practical terms.

Synthetic events can cheaply test deterministic hook behavior. The author then recommends a second tier using a real headless Claude session in a throwaway repository, where assertions depend on side effects the model cannot merely claim away. For example, whether a protected secret appeared or whether an unwanted commit actually exists.

That is the same unpleasant recursion we found locally.

We added a verifier because we did not fully trust the agent. Then we had to ask why we trusted the verifier.

There is no obvious final layer.

Why the resemblance matters

The projects above do not constitute one coordinated movement. Some are primarily security systems, some are review harnesses, one is concerned with persisted state, and another pushes a narrow class of logic into formal verification. There is no evidence that these developers are trying to converge on one standard.

What repeats is the pressure that preceded the design.

A natural-language restriction proves too weak for a hard boundary and the restriction becomes executable. An implementation agent is too close to its own reasoning and a second context appears.

Review output becomes difficult to reconstruct, so the review inputs and decisions begin surviving as artifacts. A green test cannot demonstrate that its oracle works, so somebody deliberately breaks the thing being tested. Elsewhere the trace says success but persistent state disagrees, and the verification moves to the state itself.

These are related responses, but forcing them into one architecture would erase important differences.

“Convergent evolution” is useful to us only at that level. Software has repeatedly produced similar structures when different teams encounter the same class of failure. Transactions, consensus mechanisms and least-privilege boundaries are obvious historical examples, but the analogy should not be pushed into a prediction that every coding agent will acquire the same governance stack.

We are too early for that.

These are related responses, but forcing them into one architecture would erase important differences. Separation-of-authority controls face a different problem because better reasoning does not remove the need to divide authority. Cost will eliminate another class of controls when maintaining the assurance system becomes more burdensome than the failures it was meant to catch.

The cost question matters. Every independent reviewer consumes time and tokens. Held-out tests become another thing that can rot. Receipts and digests introduce state that can go stale. A release workflow can become so defensive that developers simply find a route around it.

We already have tasks where the full machinery would be absurd. A typo does not deserve the evidentiary burden of a release-capable runtime change.

Any serious version of agent governance will eventually have to answer the proportionality problem.

“Harness Engineering” gives the surrounding system a useful name

The recurring pressure above does not make all of these projects one discipline, but a separate body of work has started treating the machinery around the model as an engineering object in its own right.

Böckeler 1 describes guides and sensors around the coding agent: mechanisms that shape what the agent sees and does, and mechanisms that expose what happened so behavior can be corrected.

The useful part for us is what follows from that. A repeated model failure does not have to remain a sentence repeated in every new conversation. If the same failure keeps returning, some part of the response can migrate into the repository itself. The response can become a test, a linter, a hook, a local rule, a tool or another structural constraint that survives after the original session has disappeared.

Zhong and Zhu 2 push the surrounding-system view further. They treat software-engineering capability as a property of a model–harness–environment system and enumerate components including task specification, context selection, tool access, project memory, task state, observability, failure attribution, verification, permissions, entropy auditing and intervention recording.

Agent runs in that framing can become auditable episode packages rather than transient interactions.

The architecture is considerably broader than our current workflow, but the places where it accumulates structure feel familiar: authority before execution, state during execution, evidence afterward, and some mechanism deciding whether the evidence is sufficient to advance.

Lin et al. 3 get close to another issue we encountered. Harness modifications are paired with predictions and later checked against subsequent task outcomes, which makes a harness edit something that can fail rather than merely become the new configuration.

Their ablation result is also worth noticing. In the reported experiments, improvements localized to tools, middleware and long-term memory, while the system prompt alone did not carry the same gain.

That does not make prompts obsolete. Our own AGENTS.md exists because semantic guidance still has work to do, especially around interpretation, scope and decisions that are difficult or foolish to encode as deterministic policy.

But a rule that repeatedly proves useful does not necessarily have to remain a sentence forever.

Repeated rules can become tests, path guards or artifact checks. Decisions that lose important context when formalized should remain judgment calls.

We do not yet know where that line should settle.

The architecture we are experimenting with now

The following sequence is not something we found in an emerging standard. It is simply a compact representation of where our own work has ended up after those failures and after looking at the systems above.

Intent
→ Scoped Authority
→ Agent
→ Tool Boundary
→ Sandbox / Policy
→ Execution
→ Runtime Evidence
→ Reviewer
→ Verifier
→ Provenance
→ Release Gate

Even written that way it looks cleaner than the real work.

Actual tasks skip stages, loop backward, become HELD before implementation is finished, invalidate yesterday's evidence after a small edit, or reveal that the environment cannot support the claim we wanted to make in the first place.

The arrows name responsibilities. They are not a transcript of debugging.

What we are trying to preserve is risk-sensitive depth.

A small local edit may need only a bounded patch, targeted tests and a diff review. A database migration can justify replay against a real fixture and inspection of resulting state.

Security-sensitive work may justify a fresh reviewer, a mutation probe or tighter execution controls. Once an agent has authority to release something, the bar changes again because its own interpretation of success can now produce an external consequence without another person necessarily intervening.

At that point AGENTS.md, hooks, skills, sandbox policy and orchestration begin to look less like miscellaneous agent customization and more like parts of a control plane, although even that phrase makes the present systems sound tidier than they are.

Some of our policy still exists only in prose because we have not found a safe or useful deterministic representation for it.

Some of our deterministic checks later turned out to encode the wrong assumption.

Moving a rule outside the model changes the failure mode. It does not make the rule correct.

PASS has become conditional language for us

After enough of these incidents, PASS stopped feeling like a state that could stand comfortably by itself.

We still use the word constantly in ordinary tests, fixture checks and contract gates.

Whenever the word appears alone, we now ask what actually passed, which artifact and observation boundary the result refers to, which environment produced it, and whether a controlled negative case could have made the check fail.

We also ask whether the evidence came from something able to rewrite it, whether the artifact has changed since verification, and what the result actually authorizes next.

Our current vocabulary is one attempt to keep those questions from collapsing:

REQUESTED
→ SCOPED
→ IMPLEMENTED
→ TESTED
→ VERIFIED
→ INDEPENDENTLY_VERIFIED
→ RELEASE_ELIGIBLE
→ RELEASED

None of these labels deserves standardization because we happen to use it. The point is to avoid assigning one state to evidence that means different things.

TESTED says something about tests. VERIFIED says that a defined claim was checked through a defined procedure.

INDEPENDENTLY_VERIFIED adds a separation the preceding state does not have. RELEASE_ELIGIBLE still does not mean the thing has been released.

When a human reads every result and decides every next action, these distinctions can remain fuzzy because human judgment fills the gaps.

When software consumes the state and chooses what happens next, the gaps themselves become executable.

We are less certain what the “agent” will mean a year from now

A large part of AI coding discussion still revolves around model capability: which model writes the better patch, which one solves the benchmark, which one can keep more of a repository in context.

Those questions remain important, but they describe a shrinking fraction of what we now spend time debugging.

We debug the model's decision, then the hook that constrained it, then the environment in which the hook executed. We find that a test passed against one artifact while the next command used another.

A reviewer can be independent in context and still depend on the same faulty fixture. A deterministic verifier can eliminate model variance while faithfully enforcing the wrong contract.

Provenance can tell us exactly where a bad decision came from without making the decision any better.

Calling the whole thing “the coding agent” starts to feel imprecise.

What we actually interact with increasingly resembles a collection of components with incomplete authority: something proposes and edits, something limits actions, something observes runtime state, something challenges the result, something records which artifact was checked, and somewhere near the end another mechanism decides whether the available evidence is enough to expose the result to the outside world.

The organizational metaphor is tempting. We can name an implementer, reviewer, verifier, policy engine, runtime and evidence store. The metaphor still has limits.

Two separately named agents running the same model against the same faulty fixture can agree very confidently. A verifier maintained through the same workflow can inherit the assumptions of the system it is supposed to challenge.

A receipt can be perfectly authentic and document a perfectly bad run.

We have not solved those problems.

What changed is that we no longer treat them as peripheral to coding-agent design. We began with an agent that wrote code and discovered, defect by defect, that a large part of the engineering burden had moved into deciding what should be allowed to count as evidence around that code.

Looking outside our own projects did not reveal a canonical architecture. It showed us that other builders were entering the same territory from different edges.

The next step cannot simply be adding every available control until the agent can barely move. We still need to work out which boundaries deserve deterministic enforcement, where probabilistic judgment remains useful, how independent a verifier really needs to be, and how much assurance a particular task can afford before assurance becomes the larger system.

The contract was not “make the process disappear somehow.” We were trying to show that a specific request traversed the lifecycle:

We do not have a clean answer to that yet.

That is the more useful place to stop.

References

Birgitta Böckeler. 2026. Harness engineering for coding agent users. MartinFowler.com / Thoughtworks.
Hailin Zhong and Shengxin Zhu. 2026. AI Harness Engineering: A Runtime Substrate for Foundation-Model Software Agents. arXiv:2605.13357.
Jiahang Lin et al. 2026. Agentic Harness Engineering: Observability-Driven Automatic Evolution of Coding-Agent Harnesses. arXiv:2604.25850.
Sondera AI. 2026. Coding Agent Hooks. GitHub repository.
Sungmin Cho. 2026. deep-review: Independent Evaluator for AI Coding Agents. GitHub repository. Related project: deep-work.
umputun. 2026. revmux: Multi-agent code review, supervised and auditable. GitHub repository.
Prudai. 2026. skeptic-audit. GitHub repository.
J. Kavanagh. 2026. AgentSkeptic — State vs Trace. GitHub repository.
Midspiral. 2026. lemmafit: Make agents prove that their code is correct. GitHub repository.
Anthropic. 2026. Claude Code Hooks Reference. Claude Code Documentation.
OpenAI. 2026. Running Codex safely at OpenAI. OpenAI, May 8, 2026.
OpenHands. 2026. Security Architecture. OpenHands SDK Documentation.
Otto. 2026. Stop your coding agent from cat-ing .env: a Claude Code hooks cookbook. DEV Community, August 11, 2026.
sai_vineeth98. 2026. A coding agent in 5 files, plus a skeptic that catches fake fixes — runs local (Ollama/vLLM). r/LocalLLM, July 23, 2026.

the interesting test is not what an agent can do, but what it takes to stop it

Sun, 30 Aug 2026 12:00:31 +0000

Most reviews of an AI agent focus on capability. Can it read the right records, does it hallucinate, is the output good enough to send to a customer. Sensible questions. They are also the wrong place to spend your caution.

An agent that is right 90% of the time and can be switched off in sixty seconds is safer to run than one that is right 99% of the time and takes a change-management window to stop. Accuracy degrades quietly. A missing off switch fails all at once, and always at the worst moment.

The blocker is rarely technical. It is that the agent borrowed a human's credential, and three other things quietly borrowed the same one. Nobody wrote that down.

So the question worth asking before deployment is not how good it is. It is: if this thing starts doing the wrong thing tonight, who can stop it, and what else goes dark when they do?

https://unlockedconsulting.ai/blog/ai-agent-identity-access-revocation

Building a long-term career in software development in the age of AI

Sat, 15 Aug 2026 05:20:36 +0000

AI agents are changing the software industry faster than many of us expected. Tasks that once required hours of coding can now be accelerated with AI, and the role of software engineers is evolving.

However, I believe the future of software development is not about humans competing with AI. It is about collaboration between engineers and intelligent tools.

AI can help us move faster, explore ideas, automate repetitive work, and improve productivity. But human engineers bring the most important elements: creativity, critical thinking, experience, empathy, and the ability to understand real-world problems.

The developers who build sustainable careers will be those who learn how to combine both strengths:

Use AI as a partner to improve productivity, not as a replacement
Build strong foundations in system design, architecture, and engineering principles
Understand business needs and create solutions that solve meaningful problems
Collaborate effectively with other engineers, teams, and AI tools
Continue learning and adapting as technology evolves

The future of software engineering will be shaped by people who can bridge human intelligence and artificial intelligence.

AI may change the way we write code, but great software will always require human vision, teamwork, and collaboration.

Software development is not disappearing. It is evolving and the best engineers will evolve with it.

The Tool-Call Loop: Building Adaptive Maintenance Workflows into LLM Wiki

Tue, 11 Aug 2026 21:59:20 +0000

Most AI-assisted tooling works in a single round trip. You send a request, the model produces an answer, you act on it manually. That model works well for queries. It starts to break down for maintenance.

Imagine you have forty wiki pages. The lint agent has marked twelve of them stale because their source files changed. The right response is to re-ingest each source file, wait for the job to complete, then run lint again to promote the freshly-ingested pages back to active. That's a well-defined sequence of steps. It's also tedious, each step requires a separate command, you have to wait for each job to finish before issuing the next, and you still have to monitor the result and decide if anything needs a follow-up.

An LLM can describe what to do. What you actually want is something that does it.

This is the reasoning behind the Agentic Maintenance Workflows we shipped in Synthadoc v1.2.0.

Static Intent vs. Adaptive Workflow

Synthadoc already had an ActionAgent before v1.2.0. It handled conversational requests like "activate the alan-turing page" or "show the lint report" by extracting structured intent from free text, executing a single action against the wiki, and returning a human-readable result. The agent was good at one-shot operations with a clear endpoint.

What it couldn't handle was anything that required waiting for state to change and branching based on the result. "Re-ingest all stale pages" isn't one action, it's a sequence that depends on knowing which pages are stale, getting user confirmation before touching anything, running one ingest job per page and waiting for each to complete, then running a lint pass on the result. The outcome of each step determines whether the next step should proceed.

The difference between the two cases is: in the first, the model extracts an intent and the code executes it. In the second, the model drives a loop — calling tools, observing results, deciding what to call next. The model isn't just a parser; it's an orchestrator.

Building a robust version of that second pattern is most of what the v1.2.0 agentic work was about.

ActionAgent as the Orchestrator

The ActionAgent already ran a simple agentic loop for single-step intents: system prompt → LLM response → parse action → execute → format result. For workflows, we extended that loop to support tool calls: the model can emit a structured tool_call in its response, the agent executes the named tool, returns the result to the model, and the model decides what to do next. This continues until the model produces a plain-text summary with no pending tool calls, which terminates the loop.

The loop has two hard constraints that we wired in from the start. Maximum 30 tool calls per action, which is enough for re-ingesting a wiki of reasonable size while preventing runaway execution. And a 120-second confirmation timeout, if the user doesn't respond to a confirm_request event within two minutes, the workflow treats it as declined and terminates cleanly. Both of these came from thinking about what failure looks like rather than what success looks like.

A single tool failure doesn't abort the workflow. If one page in a bulk re-ingest fails, the remaining pages still get processed, and the failure is recorded in the final summary. This matters for Workflow A - re-ingesting twelve stale pages and having one fail due to a temporary file lock shouldn't leave the other eleven untouched.

One thing that required careful thought: the action agent needs to route the user's intent to the correct workflow without ambiguity. We built two routing paths. For bulk re-ingest ("re-ingest stale pages", "fix stale pages"), intent extraction goes through the LLM. For by-slug re-ingest ("re-ingest the alan-turing page"), we intercept the request with a compiled regex before the LLM sees it at all. The slug-specific case is common enough, and the phrasing predictable enough, that we didn't want to pay the latency and risk of an LLM classification call for something a regex can handle reliably.

Pluggable Workflow Design

We knew from the start that "re-ingest stale pages" wouldn't be the only workflow we'd want. Lint-based promotion, dead-link cleanup, bulk archiving, all of these follow the same structure: discover scope, confirm, execute steps, summarise. Rather than hardcode each workflow into the action agent, we designed an abstract plugin interface.

The two foundational types are WorkflowContext and AgenticWorkflow. The context is a dataclass that carries everything a workflow needs: the session ID, the wiki root, the job queue, the storage layer, the audit database, an send_sse_event function for real-time progress, and the confirm registry for blocking on user decisions. The AgenticWorkflow base class declares three abstract methods: build_system_prompt(), build_initial_message(), and get_tool_fns(), and that's all a concrete workflow needs to implement. The loop machinery lives in the action agent.

IngestLintWorkflow is the first concrete implementation. It covers both execution paths: Workflow A (bulk stale re-ingest) and Workflow B (per-slug re-ingest). Both paths share the same tool set:

Tool	What it does
`find_stale_pages`	Returns all stale pages with their local source paths
`find_page_source`	Looks up any page by slug regardless of lifecycle state
`ingest_source`	Force-ingests a source file; blocks until the job reaches a terminal state
`poll_job`	Polls a job with exponential backoff until complete
`run_lint`	Enqueues a full lint pass; returns a job ID
`confirm`	Sends a`confirm_request` SSE event; blocks until the user responds

The system prompt for IngestLintWorkflow sets out the rules of operation: discover scope first, always call confirm before touching any page, process pages one at a time, run lint after all ingests complete, and produce a plain-text summary that includes every outcome. The model follows these rules because they're baked into the system prompt it operates under for this workflow, not because of any hardcoded branching in the agent.

Adding a new workflow means implementing AgenticWorkflow, registering it, and writing a system prompt. The routing logic and tool execution loop are inherited for free.

Real-Time Monitoring in the Web UI

A workflow that takes three minutes to complete and only shows output at the end is frustrating to use. The SSE protocol extensions we added in v1.2.0 address this.

Three new event types flow from the action agent to the web UI during a workflow run. tool_progress fires at each tool step, carrying the tool name, an optional job ID, and a short status message, this is what drives the inline progress display in the chat UI. confirm_request carries the payload for the Yes/No confirmation card the UI renders when the workflow calls confirm. And done.pre_prompt is an optional string field in the terminal done event that pre-fills the chat textarea with the logical next action, after a re-ingest completes, for example, the pre-fill suggests "Run lint to promote re-ingested pages to active."

The CLI command line surfaces the same SSE events through the query modal's progress display, so the agentic workflow experience is consistent whether you're working in the web UI or the CLI command line.

The Graph tab in the web UI takes this a step further. Every node in the knowledge graph has a detail panel with a Maintenance section showing two chips: "Check this page for issues" (which routes to a lint analysis) and "Re-ingest this page" (which triggers Workflow B for that node). These chips send a pre-formed chat message with the exact phrase the regex fast-path recognises, so the workflow starts without any typing or intent parsing.

Adding a New Workflow

The architecture is intentionally open. Here's what a new workflow looks like in practice.

class DeadLinkCleanupWorkflow(AgenticWorkflow):
    def build_system_prompt(self) -> str:
        return DEAD_LINK_SYSTEM_PROMPT

    def build_initial_message(self, intent: str) -> str:
        return f"Scan the wiki for dead wikilinks and surface broken references."

    def get_tool_fns(self) -> list[Callable]:
        return [tool_find_dead_links, tool_confirm, tool_archive_page, tool_run_lint]

Register it in the workflow router, add the routing phrase, write the system prompt, and the loop machinery handles execution. The workflow inherits confirm support, SSE progress events, the 30-call limit, and the 120-second confirmation timeout automatically.

The reason this pattern works is that the loop logic — tool dispatch, result injection, termination detection — is completely generic. The only workflow-specific parts are the tools it can call and the instructions it operates under. Everything else is shared infrastructure.

What We Learned, and Where This Goes

Building agentic workflows into a tool-call loop surface area taught us a few things.

Confirmation is load-bearing. The confirm tool isn't a courtesy, it's a safety requirement. Without it, the workflow would discover twelve stale pages and immediately start re-ingesting them without giving the user a chance to review the scope. Adding a user-approval gate before any destructive operation turns the workflow from "something that does things to your wiki" into "something that shows you what it's about to do, then does it with your permission." The 120-second timeout defaults to declined rather than approved, for the same reason.

Per-step tool progress makes everything feel faster. A workflow that takes ninety seconds with no intermediate output feels like it hung. The same workflow with a progress event at each tool step, "Ingesting alan-turing... done. Ingesting ada-lovelace... done." , feels responsive. The actual duration is identical. The perceived latency is completely different.

System prompts are the policy layer. The rules governing how a workflow operates — what order to call tools in, when to stop, how to format the summary — live in the system prompt. This means they're human-readable, version-controlled, and adjustable without touching the execution machinery. When we needed to change the ordering behaviour for Workflow B (look up source path before confirming, not after), we changed four lines of the system prompt and redeployed. No code change.

The natural next extensions are workflows that can operate on a schedule, a nightly stale-page sweep that runs unattended, and workflows that can initiate from lint signals rather than user requests. Both require the same pluggable pattern; they just need a different trigger mechanism. That work is in the roadmap for a future release.

See It Running

The walkthrough below covers the full loop end to end: two stale pages, the confirmation gate, per-page ingest progress, lint auto-run, and the final page-state report showing whether each page reached active.

📺 Synthadoc Agentic Maintenance Workflow — YouTube

How Long-Horizon AI Tasks Break Short-Horizon Safety Assumptions

Tue, 21 Jul 2026 09:07:41 +0000

Most AI safety work was designed around a single exchange: prompt in, response out. Long-horizon agents - models that run autonomously over minutes, hours, or many sequential steps - expose a different class of failure entirely.

The Core Problem: Compounding Ambiguity

A one-shot model either answers well or it doesn't. A long-horizon agent makes dozens of small decisions, each one reasonable in isolation, that can compound into a large unintended outcome. The safety problem shifts from "did the model give a bad answer?" to "did the model stay aligned with the original intent across 50 tool calls and three context windows?"

Two failure patterns show up repeatedly in deployed agentic systems. First, goal drift: the agent optimizes toward a proxy objective that diverges from what the user actually wanted, especially when the original instruction becomes buried in a long context. Second, irreversibility creep: early actions narrow the solution space, and by the time the agent reaches a decision point that matters, it has already locked in assumptions the user never explicitly approved.

The classic guardrails - output classifiers, refusal triggers, content filters - run at the end of a single generation. They don't catch a chain of individually acceptable steps that collectively produces a problematic result.

Real Example: A Checkpoint Pattern for Agentic Pipelines

One practical mitigation is injecting explicit alignment checkpoints - pauses where the agent surfaces its current plan and intermediate state before continuing.

def run_with_checkpoints(agent, task, steps_per_check=5):
 results = []
 for i, step in enumerate(agent.plan(task)):
 result = agent.execute(step)
 results.append(result)
 if (i + 1) % steps_per_check == 0:
 summary = agent.summarize_progress(results)
 approval = input(f"Step {i+1} summary:\n{summary}\nContinue? (y/n): ")
 if approval.lower() != "y":
 agent.rollback(results)
 break
 return results

This isn't a production-ready framework - it's the pattern. The agent surfaces its working state at regular intervals rather than running dark until completion. For fully automated pipelines where human-in-the-loop isn't feasible, the same idea applies programmatically: log a structured state snapshot at each checkpoint, run a lightweight secondary model to flag divergence from the original goal, and halt if confidence drops below a threshold.

The checkpoint frequency is a tunable tradeoff - tighter intervals catch drift earlier but add latency and cost. For high-stakes or irreversible actions (API calls that write data, send emails, deploy code), checkpoints before those steps specifically are non-negotiable.

Key Takeaways

Safety methods built for single-turn models don't automatically extend to multi-step agentic workflows - the failure modes are structurally different.
Goal drift and irreversibility creep are the two most common long-horizon failure patterns; both require proactive checkpoints, not just output filters.
Checkpoint frequency should scale with action reversibility - irreversible steps need explicit review regardless of how many steps have passed.

If you're running an agentic pipeline today, what's the longest it runs without surfacing its intermediate state for any form of review?

Sources referenced: OpenAI Blog - Safety and alignment in an era of long-horizon models

Hiring Agentic AI Engineers? This one question you could ask to separate the real talent from others

Thu, 14 May 2026 05:01:09 +0000

Hiring Agentic AI Engineers?

This one question you could ask to separate the real talent from others.

Agentic AI engineering isn’t just about calling APIs or writing flashy prompts.

It’s about building real solutions that work for real users.

So, a question that could work is

“What edge cases did you solve while building the AI Agent?

This question is important because building an AI Agentic system is not a difficult task, but making it work for the edge cases and tradeoffs is the real deal

You want engineers who:

– can build for users, not just for a hackathon demo.

– can debug the problem, not just the code.

– can think in terms of systems, not just LLMs.

Additional things to check

– Combine Gen AI building blocks (RAG, vector DBs, guardrails, security, deployment etc.) like Lego masters

– Use AI coding Agents to ship faster, but know when to take the wheel themselves

– Learn deeply: Not just consuming YouTube videos but digging into papers and repos.

Great Agentic AI engineering isn’t about adding AI Agents everywhere, but about adding them where they truly move the needle.

Pixparkle - Chat-based AI Image Generato

Mon, 11 May 2026 12:34:33 +0000

The problem

Most AI image tools want you to learn their dialect before they will give you anything useful. Midjourney expects slash commands and weighted prompt syntax in Discord. DALL-E gives you one shot per request, and if the result is almost right you start over and hope. Firefly bundles the workflow inside a Creative Cloud subscription you may already be paying for under another line item.

Two failures keep showing up across all of them. The first is text rendering. Logos turn into glyph soup, signage in product mockups comes back as nonsense, and CJK characters fall apart. The second is iteration. You can describe the image perfectly on attempt seven, except the model has no memory of attempts one through six, so refinement is really starting over with extra context glued onto your prompt.

Pixparkle is what came out of trying to fix both problems in one product.

What Pixparkle is

Pixparkle is a chat-based AI image generator. You describe the image in plain language, see the result, and refine it through follow-up messages in the same conversation. The model keeps the context, so "make the lighting cooler" or "swap the logo color to lime green" works the way you would expect when talking to a designer.

Under the hood, Pixparkle runs on Google's Nano Banana model family plus a Flux Fast tier for quick drafts. You can switch between models mid-conversation without losing the thread:

Flux Fast: 1 credit per image. Best for rapid volume work where speed beats polish.
Nano Banana: 2 to 5 second draft generation at 1K resolution. 5 credits per image.
Nano Banana 2: 4 to 6 second generation up to 4K, ultra-wide aspect ratios (8:1, 1:8, 4:1, 1:4), and an Image Search tool. 7 to 14 credits.
Nano Banana Pro: Built on Gemini 3 Pro with a thinking stage that analyzes composition, lighting, and palette before generating. Best aesthetic quality and best text rendering. 10 to 20 credits.

A single chat session can drop from Pro down to Nano Banana for cheap variants, then climb back up to Pro for the final hero shot. You never have to re-explain the brief.

Capabilities that change the workflow

Accurate text rendering. Nano Banana Pro handles English, Chinese, Japanese, Korean, and several other languages. Headlines, signage, product label copy, and short paragraphs all come out readable. For e-commerce product cards, YouTube thumbnails, and educational diagrams, this removes the round trip through Photoshop where you would normally redo the text by hand.

4K output (3840x2160). Most consumer AI image tools cap at 1024 or 2048 pixels. Pixparkle generates up to 4K, which is the resolution you actually need for printed packaging, large-format posters, and crisp hero banners on retina displays.

Up to 14 aspect ratios. Square, portrait, landscape, widescreen, 9:16 reels, 16:9 thumbnails, and ultra-wide 8:1 or 1:8 banners. The available set depends on which model you pick. You stop cropping a single output across five platforms and generate the right ratio per surface from the same conversation.

Reference image editing. Drop in an existing photo and edit it through chat. Replace backgrounds, recolor elements, swap props, or apply a style direction. Useful when you already have a hero asset and need ten variants without rebuilding it from scratch.

Character consistency. Nano Banana Pro keeps the same character identity across multiple scenes. Generate a brand mascot once and place that mascot in a dozen different compositions without it morphing into someone else.

A typical chat looks like this

You: "Product photo of a dark chocolate bar on a walnut surface, moody lighting, with the brand text TASTE THE SPARKLE on the wrapper in chartreuse foil."
Pixparkle: returns the image in 4 to 6 seconds.
You: "Cooler highlight from the upper right, and scatter a few yuzu segments around it."
Pixparkle: returns a refined version.
You: "Switch to Pro at 4K and add a SHOP THE DROP CTA at the bottom left."
Pixparkle: returns the final version with sharp text and the requested layout.

There is no prompt template to memorize. If you can write the brief, you can drive the tool.

Who it lands with

E-commerce sellers running 50 to 500 SKUs. The credit math typically lands at a small fraction of studio photography for a comparable batch, and the white-background and lifestyle outputs are Amazon and Shopify spec compliant.

YouTube and short-form creators who used to spend two hours per thumbnail in Photoshop. A typical session covers three to four A/B variants in five minutes with the headline rendered directly inside the image.

Social media managers running multiple brand accounts. Generate the hero asset once, then ask for 9:16, 1:1, and 16:9 variants with consistent typography and color in the same chat.

Educators and technical writers producing illustrated explainers with accurate multilingual labels.

Pricing

Credit-based. You pay for what you generate.

Plan	Price	Credits
Free	$0	10
Pro Monthly	$9.90 / mo	500
Premium Monthly	$29.90 / mo	2,000
Pro Yearly	$99.90 / yr	6,000
Premium Yearly	$299.70 / yr	18,000

No credit card to start. The 10-credit free tier works across all four models, so you can sanity-check the output quality on the models you actually care about before paying anything.

Stack notes for the engineers in the room

Pixparkle runs on Cloudflare Workers via OpenNext, Next.js 15 App Router on the frontend, Tailwind v4, and Drizzle ORM over Cloudflare D1. Image generation calls go out to Gemini and Replicate, with results stored in R2. Auth is NextAuth v5 with Google OAuth.

State for long-running generation jobs and the credit reservation system lives in Durable Objects. Queues handle async post-processing. The whole thing ships globally on the Cloudflare edge, which is most of why the latency feels closer to a chat app than to a typical AI image pipeline.

A public API is on the roadmap. If you are building something that needs chat-based image generation as a primitive and want early access, reach out in the comments.

Try it

Free tier is open at https://pixparkle.com/. No credit card required. 10 credits land in your account when you sign in with Google.

Feedback welcome in the thread. The things I am most curious about: what your text-rendering tests look like in non-Latin scripts, and whether multi-model switching inside a single chat matches how you actually want to iterate.

AI vs LLM vs AI Agents vs Automation — What’s the Real Difference?

Tue, 05 May 2026 09:04:51 +0000

These days, you hear these terms everywhere:

AI
LLM
AI Agents
Automation

And honestly…

They often get mixed up.

So let’s clear it in a simple, practical way

1. What is AI?

AI (Artificial Intelligence) is the big umbrella.

It means machines that can perform tasks that normally require human intelligence.

Examples:

Image recognition
Speech recognition
Recommendation systems (like YouTube, Netflix)

So remember:

AI = everything smart done by machines

2. What is an LLM?

LLM = Large Language Model

This is a type of AI focused on language.

Examples:

Chatbots
Code generation
Text summarization

LLMs are trained on massive text data and can:

Understand prompts
Generate responses
Write code

So:

LLM ⊂ AI (subset of AI)

⚙️ 3. What is Automation?

Automation is different.

It means doing tasks automatically using predefined rules.

Examples:

Sending emails automatically
Running scheduled jobs
CI/CD pipelines

Important:

No intelligence required
No learning
Just rules + triggers

So:

Automation = “Do this when that happens”

4. What are AI Agents?

AI Agents are the next level.

They combine AI + decision-making + actions

An AI agent can:

Understand a goal
Plan steps
Use tools (APIs, browser, code)
Execute tasks

Example:

“Book a flight for me”

Agent will:

Search flights
Compare prices
Fill forms
Complete task

That’s beyond just answering.

Simple Comparison

Concept	What It Does	Intelligence Level
AI	General smart systems	High
LLM	Works with text/language	High
Automation	Executes predefined tasks	Low
AI Agents	Think + decide + act	Very High

Easy Way to Understand

Think like this:

Automation = Robot following instructions
LLM = Smart brain for language
AI = Entire intelligence field
AI Agent = Smart assistant that can act

⚡ Real Example

Let’s say:

“Send a report every day”

Automation:

Sends report at 9 AM daily

LLM:

Can generate the report text

AI Agent:

Collects data
Generates report
Sends email
Adjusts based on changes

Huge difference.

Why This Matters for Developers

Understanding this helps you:

Choose the right tools
Build smarter systems
Avoid confusion
Stay relevant in AI-driven development

Because today:

Developers are not just coding
They are building intelligent systems

Final Thought

Not everything is AI.

Not every AI is an agent.

Not every system needs intelligence.

The real skill is knowing what to use, where.

And that’s what makes a smart developer in 2026

What do you think is the future — Automation or AI Agents?

Let’s discuss

AI #LLM #AIAgents #Automation #Developers #SoftwareEngineering #TechExplained

I built AgentKit because my AI coding agent kept failing — here's what I learned

Sun, 12 Apr 2026 07:15:09 +0000

The frustration that started everything

I'd been using Claude Code and OpenCode daily for months. The models were impressive — genuinely capable of understanding complex codebases, writing solid logic, catching bugs I missed. But there was a pattern I couldn't shake: give it a real task, something with more than two or three steps, and it would fall apart halfway through. Not because it was dumb. Because it had no discipline.

It would skip reading the relevant files and just start writing. It would forget what it decided three prompts ago. It would use the most expensive model for a task that needed a two-line answer. Every session felt like handing the wheel to someone brilliant who had no memory of the drive so far.

Task completion — on anything non-trivial — hovered around 20%. That's not a model problem. That's a structure problem.

What I actually built

AgentKit is an open-source workflow layer that sits on top of AI coding agents and gives them what they're missing: a memory, a plan, and a process they have to follow before touching your code.
It has five core layers:

The Intelligent Skill Router : classifies every prompt and injects only the relevant skills into context — cutting token usage
by ~89% per session. The agent stops reading 45,000 tokens of
documentation it doesn't need and reads the 5,000 it does.
The Project Memory Graph: is a SQLite-backed knowledge graph that records every file, function, API route, and architectural
decision across sessions. When you start a new session, AgentKit
already knows what you were building, what you decided, and why.

The Token Budget Intelligence layer :automatically routes simple tasks to cheaper models and complex ones to powerful models. Against
an all-Sonnet baseline, it cuts costs by around 60%. The Workflow
Engine is the most important piece. It enforces a strict Research →
Plan → Execute → Review → Ship state machine. The agent literally
cannot edit a file without an approved plan. No shortcuts. No jumping
ahead.

The Universal Platform Layer means none of this is locked to one tool. AgentKit installs across 11 platforms — Claude Code, OpenCode,
Hermes, and more — with a single command.

The moment the benchmark landed

I ran the same tasks with the same model — Gemma 4 31b — with and without AgentKit active. Same prompts, same codebase, same evaluation criteria.

Without AgentKit: ~20% task completion.
With AgentKit: ~80%.

I ran it twice because I didn't believe it the first time. The difference is entirely structural. Planning before execution changes everything. Not the model. The process.

Where it is now:

AgentKit is live, open source, and published on npm. We're at v0.5.x — early, but stable enough that developers are cloning it daily and the Skill-Sync Bridge is already auto-generating new skills from session experience.

The project is also starting to get attention from the developer community, including a benchmark writeup that landed on Dev.to.

The preview version (agentkit-preview) goes further — a Telegram bridge for 24/7 remote agent control from your phone, an approval gate system so the agent can never auto-execute without your confirmation, and a self-improving skill library that grows from your own sessions.

Try it

npx agentkit-ai@latest init

GitHub: https://github.com/Ajaysable123/AgentKit

If you are running LLMs in production, you have probably seen this:

Thu, 05 Mar 2026 07:36:17 +0000

If you are running LLMs in production, you have probably seen this:

Models slowing down when reasoning gets deep
Fewer users per server than expected
GPU bills rising fast

The problem isn’t compute.

It’s memory.

When models “think” step by step, they store every reasoning token in GPU memory (KV cache).

The longer they think, the larger this cache becomes.

Memory grows linearly. Costs grow with it.

So teams face a trade-off:

Let the model think longer → better accuracy → higher infra cost

Limit thinking → lower cost → weaker performance

To solve this proble, Nvidia introduced something interesting: Dynamic Memory Sparsification (DMS).

Instead of keeping every token, the model learns what to keep and what to evict, intelligently.

Even better, it doesn’t delete things immediately. It briefly keeps “maybe useful” tokens before removing them. That avoids hurting reasoning quality.

How?

They add a small decision layer inside the attention mechanism. For every token, the model also predicts whether that token will matter for future reasoning.

During training:

Most of the model is frozen.

Only this “memory policy” is trained.

If deleting a token changes the final answer, the model is penalized.

So it gradually learns:

“If removing this breaks my reasoning → keep it.”

“If nothing changes → it’s redundant.”

There’s also a safety mechanism called delayed eviction. Tokens aren’t deleted instantly - they’re kept briefly so the model can absorb any remaining signal before removal.

The impact?

• Up to 8× lower memory cost

• Up to 5× higher throughput

• In some cases, better reasoning under the same budget

As AI systems move from simple chat to multi-step reasoning agents, memory, not compute, may become your biggest constraint.

Worth watching closely.

What is Google's Universal Commerce Protocol (UCP)

Thu, 19 Feb 2026 05:49:55 +0000

Do you trust AI agents to buy things on your behalf?

One concern is obvious that they can make mistakes.

But there are also technical issues: the current infrastructure is not built for AI Agents.

Every store has its own APIs
Every payment system works differently

For AI agents, it’s chaos.

An AI that wants to shop across 1,000 websites would need 1,000 separate integrations.

To solve this, Google has introduced Universal Commerce Protocol (UCP)

UCP is a standardised way for AI agents transact online.

Here’s how it solves problem:

UCP creates a common language layer between:

AI agents
Retailers
Payment systems

So instead of:

AI → Custom Store API → Custom Checkout → Payment

It becomes:

AI → UCP Standard → Store + Payment Network

One structure. Many participants.

Google has built UCP with major ecommerce platforms like Etsy, Shopify, Target, Walmart, and Wayfair plus payment giants like American Express, Mastercard, Stripe, and Visa.

So this isn’t a feature rollout. It’s an ecosystem move.

What do you think, how soon you will be trusting AI Agents to do shopping on your behalf?

Can an AI Agent manage its memory on their own?

Tue, 17 Feb 2026 05:45:41 +0000

One of the biggest limitations of AI agents today is that they do not have internal memory.

We have to manage their memory explicitly.

But what if an AI agent could edit, update, and manage its own memory...

In this video, let us see how to do the same.

Code Notebook - https://lnkd.in/gPKgAiBq

About "AI ML etc."

We have reimagined AI education for senior IT professionals and specifically designed AI courses/ programs for them.

If you have 10+ years of IT experience and would like to learn to lead AI initiatives confidently, this course is for you!!

These courses are production-focused, relevant, hype-free, and short.

Learners from 160+ reputed organisations like Microsoft, Nvidia, Aricent, Infosys, Maersk, Sapient, Oracle, TCS, Genpact, Airtel, Unilever, Vodafone, Jio, Sterlite, Vedanta, iDreamCareer and more have taken our courses and attended our lectures

More details here - https://lnkd.in/grF-8hh8