DEV Community: agents

Memory Doesn't Exist — You're Just Forging History

leo-wang — Fri, 14 Aug 2026 06:58:43 +0000

There's a team whose death I remember especially well. They built a customer-service Agent with a "user profile" — a user says "I'm a VIP customer, Zhang Wei" once, and in every conversation after the Agent "remembers." The product manager asked in the demo: "Will you remember me?" — "Of course, I'll always remember you, Mr. Zhang." They high-fived and shipped. Day one in production, a customer reported: "Your AI says it doesn't know me."

No line of code was wrong. What was wrong was the assumption that conversation.append() could hang memory onto the model. The LLM API is a pure function — response = f(messages, params). No session, no cookie, no cross-request state. From the moment they shipped, they were just stuffing a long chat log back into the API verbatim every time: forget to stuff, truncate, or restart the container, and the memory never existed. The essence of memory lives in your code and your database, not the model.

My take: the Memory layer's engineering maturity is often the decisive factor in whether a system can ever reach shipping. Models can be swapped, frameworks rewritten — but if the Memory layer is designed wrong, all prior conversation data is garbage and you start over. That's why this series places Memory ahead of Frameworks.

Read the full 60-article series — $79 one-time, lifetime access → https://buy.stripe.com/5kQ6ozeEsbKabvzdMQ97G00

Production-Grade AI Agents — by Leo Wang · Follow on X · Subscribe

Nobody counts guardrails the same way twice, so "we added guardrails" tells you nothing

James O'Connor — Fri, 14 Aug 2026 06:58:04 +0000

TL;DR: Counting what six guardrail tools ship is harder than it sounds, and I got one of them wrong on the first pass. The answers are 27, 0, 12 or 31, 14, 12 plus 15 plus 4, and one that cannot be counted at all. The numbers are not comparable, because the six do not agree on what a guardrail is or on who maintains the list, and two of them turn out to have the same architecture. The useful question is where the list lives.

Someone on my team said "we added guardrails" in a design review last month, and I nodded, and two weeks later I found out we had shipped a regex.

That is a review problem, and I could not fix it without a definition. So I tried to answer what looked like an easy question, which is how many checks each of the main guardrail tools gives you when you install it. It took three passes, and the interesting part is what went wrong in the first two.

Pass one, I read the docs, which was useless. Docs are written to describe capability, so they list things that are optional, paid, or on a roadmap, and I needed the set that lands on disk when you install. Pass two, I read one file per project and got a clean set of numbers, one of which was wrong by a factor of six because I had read the wrong file. Everything below is pass three, from source as of August 2026, with paths, including the correction.

The axis, and what I refused to count

The axis is narrow on purpose: how many distinct checks arrive when you install the thing, and who maintains that list. Not accuracy. Not latency. Not price.

I refused to count three things. Anything listed in docs but absent from the tree, because docs describe intent. Anything that wraps another vendor's detector, which I counted against that vendor. And anything behind a closed API, where there is no tree to read, which I report as unknown rather than guessing.

The six, by what ships

LLM Guard (Protect AI, open source, and archived). Worth knowing before you adopt it: the repo is read-only, last pushed 8 July 2026. In the 0.3.16 wheel, the two init.py export lists hold 15 input scanners and 22 output scanners, 37 entries. 10 names appear in both lists (BanCode, BanTopics, Toxicity, Regex and six more), so the distinct count is 27. Input-only: Anonymize, PromptInjection, Secrets, TokenLimit, InvisibleText. Output-only includes Bias, FactualConsistency, MaliciousURLs, NoRefusal, Relevance, URLReachability, Deanonymize, JSON, among others. Even at 27 this is the largest in-box inventory here, and I flag the 37-versus-27 gap because the summed number is the one usually quoted.

Two caveats that cost me a rewrite. The repo's main has 28. It carries an EmotionDetection scanner in both registries that appears in no released wheel, and since the repo was archived on 8 July 2026 it never will. I had 28 in an earlier draft of this post because I counted GitHub instead of the artifact, which is exactly the error this post is about, committed by the person writing it. And the 27 is not all LLM Guard's own work: Anonymize and Sensitive import Microsoft's Presidio, Secrets wraps Yelp's detect-secrets, and 23 of the modules pull in transformers to run third-party checkpoints. It is not exempt from the boundary problem below. It just draws the boundary inside the package instead of in a directory name.

Guardrails AI. Zero validators in the core package. guardrails/validators/init.py exports Validator, register_validator, ValidationResult, PassResult, FailResult and ErrorSpan, and stops. That is the architecture working as designed: validators live in Guardrails Hub as separately installed packages, and the core ships the base class and the registration machinery. The catalogue is real and large. It simply is not in the box, which means your dependency set and your check set become two lists that drift independently.

NVIDIA NeMo Guardrails. 31 rail directories under nemoguardrails/library/ (32 subdirectories, one of which is utils). By my reading, 12 are checks NVIDIA implements: attention, content_safety, context_bloat_detection, factchecking, gliner, hallucination, injection_detection, jailbreak_detection, regex, self_check, sensitive_data_detection, topic_safety. The other 19 are adapters to someone else, including activefence, autoalign, cleanlab, fiddler, patronusai, privateai, prompt_security, trend_micro, llama_guard and guardrails_ai. The boundary is fuzzy at three of the twelve. gliner wraps a third-party model (GLiNER is urchade's, not NVIDIA's), sensitive_data_detection/actions.py imports presidio_analyzer and presidio_anonymizer throughout, and factchecking leans on an external AlignScore server with a self-check fallback. Count all three as wrappers and the split is 9 own to 22 adapters. (hf_classifier is a wrapper as well, but it already sits in the 19.) Either way, 31 and 12 are both true and answer different questions.

Llama Guard 4 (Meta, 12B). Not a library. A model with a fixed taxonomy of 14 hazard categories, S1 through S14: Violent Crimes, Non-Violent Crimes, Sex-Related Crimes, Child Sexual Exploitation, Defamation, Specialized Advice, Privacy, Intellectual Property, Indiscriminate Weapons, Hate, Suicide and Self-Harm, Sexual Content, Elections, and Code Interpreter Abuse (text only). From Llama-Guard4/12B/MODEL_CARD.md in meta-llama/PurpleLlama. You run inference and get a label plus a category. There is no plugin surface.

Future AGI. This is the one I got wrong. Reading futureagi/ee/protect/helper.py gives four hosted metrics (toxicity, bias, privacy/PII, prompt injection) mapped in _UI_TO_METRIC, and I nearly published "four, the smallest inventory here". That file is the hosted metric map, not the inventory. agentcc-gateway/internal/guardrails/ holds 18 directories: external/ carries 15 vendor adapters as single Go files (lakera.go, presidio.go, llamaguard.go, bedrock.go, azure.go and ten more), futureagi/ is a client for Future AGI's hosted eval API, configured with whichever eval IDs you name (the Protect surface in futureagi/ee/protect/helper.py is the one that maps to four metrics), and of the remaining sixteen about twelve read as in-tree detectors (blocklist, contentmod, hallucination, injection, language, leakage, mcpsec, pii, secrets, sysprompt, toolperm, topic) with the rest closer to plumbing. The gateway README says 18 built-in scanners; I count about twelve that read as detectors, the same gap I flagged on LLM Guard's 37.

One thing the count does not show: those twelve are pattern matchers. hallucination/hallucination.go is a list of compiled regexes scoring matchCount * 0.2, and its own comment says to use Future AGI's hosted guardrail models for proper factuality verification. topic, injection, leakage, pii and contentmod are regex and phrase lists too. So twelve here is not the same kind of twelve as NeMo's, which includes LLM-backed self_check, factchecking and content_safety. Same architecture, own scanners plus a wall of third-party adapters, and a shallower own layer.

Lakera Guard. Hosted, closed source. There is no public tree to count, so I am not publishing a number for it. Whatever the docs list on the day you read them is the inventory, and it can change without a version bump you control. Someone else maintaining detector quality is a real benefit, and not being able to diff it is a real cost. Claiming I had verified a count would have been worse than leaving it blank.

The comparison table

Tool	Checks shipped on install	Where the list lives	Verified in
LLM Guard	27 distinct (37 export entries, 10 shared); several delegate underneath	In the pip package, archived 07/2026	`llm_guard/{input,output}_scanners/__init__.py` (0.3.16 wheel)
Guardrails AI	0 in core	Guardrails Hub, installed per validator	`guardrails/validators/__init__.py`
NeMo Guardrails	12 own plus 19 adapters (31 rails)	In the package, but 19 delegate	`nemoguardrails/library/`
Llama Guard 4	14 hazard categories, fixed	In the model weights	`Llama-Guard4/12B/MODEL_CARD.md`
Future AGI	~12 in-tree regex checks, 15 vendor adapters, 4 hosted metrics	Split: in the gateway tree, and vendor-side	`agentcc-gateway/internal/guardrails/`, `futureagi/ee/protect/helper.py`
Lakera Guard	not determined (no public tree to read)	Vendor-side, changes without your release	closed source

Check the LLM Guard number yourself

The central count takes about ten seconds to reproduce, which is the point of publishing the paths:

# 0.3.16 is the last release (repo archived 8 July 2026). Its requires_python is
# >=3.10,<3.13, so this pinned download only works on 3.10, 3.11 or 3.12. On 3.13+
# pip errors with "No matching distribution found" rather than quietly falling back.
# The repo's main branch has one more scanner, EmotionDetection, that shipped in no
# release at all: main says 28, the artifact says 27.
pip download llm-guard==0.3.16 --no-deps -d /tmp/lg && cd /tmp/lg && unzip -o -q llm_guard*.whl
python - <<'PY'
import ast
def names(p):
    tree = ast.parse(open(p).read())
    for node in ast.walk(tree):
        if isinstance(node, ast.Assign) and getattr(node.targets[0], "id", "") == "__all__":
            return {e.value for e in node.value.elts} - {"get_scanner_by_name"}
    return set()
i = names("llm_guard/input_scanners/__init__.py")
o = names("llm_guard/output_scanners/__init__.py")
print(len(i), len(o), len(i & o), len(i | o))   # 15 22 10 27
PY

Three things the count tells you

Zero can be the honest answer. Guardrails AI shipping no validators in core is the design behaving correctly. The cost is that "which checks are we running" stops being answerable from your lockfile. If you go that route, write down on day one where the list lives and who may change it.
A fixed taxonomy buys a property the extensible ones cannot. Llama Guard is the only one of the six in this category: 14 categories, fixed in the weights, no plugin surface at all, so the behaviour you test in staging is the behaviour you get in production. It will not cover a case outside its taxonomy, and it will not surprise you with one either. Whether that trade is right depends on whether your risk surface is narrow enough to fit inside it, and for most teams it is not. Note that this is the property I nearly credited to Future AGI on the strength of its four hosted metrics, before its gateway tree showed me fifteen vendor adapters and a plugin registry.
A big number can mean the vendor did less work, and two of these six are the same shape. NeMo's 31 is the obvious case, since 19 of those directories are adapters. Future AGI's gateway is the same architecture: roughly a dozen in-tree scanners wrapped around fifteen vendor adapters. An adapter layer is useful, and for either project it is a fast way to put several vendors' detectors behind one config, but it is an integration achievement rather than a detection one, and it means the two projects I would have described as opposites are structurally siblings. The same trap sits inside LLM Guard's own headline, where 37 export entries turn out to be 27 detectors, and inside my own first draft, which said 28 because I counted a branch instead of a release. Every number on this page needed a second look before it meant anything, which is the actual finding.

What this changes about the review conversation

"Did we add guardrails" is not answerable. Three questions that are:

Which named checks run, on input, on output, per route?
Where is that list defined, and does a change to it show up in our diff?
What happens on the check's own failure path: does the request proceed, or stop?

Ask them per tool call, not per app, which is where this bites for anyone shipping agents: an agent that can hit a payments API and a search API through the same runtime does not want one guardrail config, and "which checks run on this route" is a different answer for the two. Question 2 is what separated the six tools above, and it is the one nobody asks in a design review. Question 3 I have left open. Answering it properly means reading six exception paths and reasoning about timeouts under load, and I would rather ship five counts I verified than six behaviours I inferred. It is the better question, and I have not earned an answer to it yet.

Where I'd push back on this

Counting checks is a shallow axis and it implicitly rewards quantity, which is the objection I would lead with if I were reading this. Fair. One well-tuned prompt-injection detector that fits your traffic beats twenty-eight that do not, and nothing in these numbers says whether a given detector works on your data. I picked this axis because it is verifiable from source and because it exposes the packaging differences that make the usual vendor comparison meaningless.

An objection I would also accept: leaving Lakera's cell empty while everyone else gets a number reads as a penalty. A closed-source tool is not worse for being closed, and plenty of teams are glad to have a vendor own detector quality. The empty cell records what I could verify, not a judgement about the product.

An objection I would not accept: that the Guardrails AI zero is a cheap shot. It is what the file exports. A reader who installs the core package expecting validators gets a base class, and that is better learned before the sprint than during it.

Source references checked August 2026. These trees move. The paths are in the table so you can re-run the counts rather than trust mine.

A coding agent needs an authority budget, not just a better model

hefty — Fri, 14 Aug 2026 06:43:32 +0000

A coding agent can produce a patch before your team has agreed on what it was allowed to read.

That is a bad trade. A fast patch is not useful if nobody can explain which files shaped it, which tools it called, what data it retained, or what evidence makes the result trustworthy. The model may be capable. The workflow can still be unusable.

I think about this as an authority budget. The budget is the set of permissions and obligations around an agent: what it can read, write, call, retain, ask approval for, and prove afterward. The model matters, but it is only one part of the operating design.

Model quality is only one axis

Coding assistants now occupy different workflow lanes. Some live in an IDE. Some work in a terminal, browser, or pull-request flow. Privacy, team controls, cost, and the amount of context available also vary by tool.

That variety makes a universal ranking less useful than it looks. Choosing an agent is also choosing a permission surface.

An IDE assistant may see the file currently open and a slice of the repository. A terminal agent may be able to run commands and modify a wider set of paths. A browser-oriented workflow may have a different kind of access again. Each one creates a different review problem.

The question is not only, "Which model writes the best code?" It is also:

What context does this workflow expose?
What can the agent change without asking?
Which external systems can it call?
How does a reviewer know what happened?

A model comparison can help with the first question. It does not answer the rest.

Reading, writing, and reviewing are different powers

The Pair documents a simple split between a Mentor, which acts as a read-only reviewer, and an Executor, which performs the writing work. Whether that project catches more mistakes is a separate question. The design still makes an important permission distinction visible.

Inspection and mutation do not have to be the same authority.

That distinction is easy to lose when one agent can inspect a repository, edit files, run commands, and summarize its own work. The same system that made the change can also decide that the change looks fine. A successful response then becomes a weak substitute for independent review.

A stricter workflow can separate the powers:

One step gathers context and proposes a change.
Another step applies the change inside a bounded workspace.
A reviewer, human or automated, inspects the diff and the required checks.

This does not make the review correct by magic. It does make the review boundary explicit. Read access is not write access, and write access is not approval.

The harness around the model is part of the product

Google's developer highlights describe persistent isolated environments and Managed Agents as part of its developer tooling. The release signal matters because it treats execution space, persistence, and agent lifecycle as product concerns rather than details hidden behind a chat box.

The Product Hunt page for prjct/ takes a similar direction from a different angle. Its product positioning combines intent briefs, bounded repository context, persistent memory, guardrails, and evaluations around coding agents.

Those pages describe vendor or product-authored capabilities. They are not independent validation, and isolation or persistence does not automatically make a workflow safe. They do show where the engineering surface is moving: the wrapper around the model increasingly determines the context, tools, memory, and checks that shape a run.

That wrapper deserves the same design attention as the prompt.

If an agent has persistent memory, decide what enters it and how long it stays there. If it runs in an isolated environment, decide which credentials, network routes, and repositories can still reach the environment. If it has guardrails, make the restricted actions visible and test the failure path.

A label such as "sandboxed" is not a permission model.

Why teams say no

A recent Reddit discussion about a workplace that did not allow AI agents is anecdotal, not a measurement of how teams behave. It is still useful because the objections are concrete. People discuss code exfiltration, data retention, residency, and how a reviewer can examine agent-produced changes.

Those are authority questions.

A developer may want help with a repository. The organization may need to know whether source code leaves its boundary, whether prompts or logs persist, where artifacts are stored, and whether a human can reconstruct the change. Productivity does not remove those obligations.

This is why "the model is good enough" rarely settles an adoption decision. A team can accept the coding capability and reject the surrounding authority. It can also approve a narrow local workflow while refusing broad repository or production access.

Write the six lines before widening access

The authority budget does not need to be a grand governance program. Start with six explicit lines in the task definition.

Read. Name the repositories, directories, files, secrets, and external context the agent may see. Keep sensitive material out of scope by default.
Write. Name the paths and branches the agent may change. Make generated artifacts and protected files clear.
Call. List the commands, tools, network destinations, and services available during the run. Treat a new network permission as a design change.
Retain. Decide where prompts, source snippets, memory, logs, diffs, and output artifacts persist, and for how long.
Approve. Mark the actions that require a person or a policy gate, such as changing dependencies, accessing production, or widening the workspace.
Prove. Require the diff, named check results, relevant event or log evidence, and an explicit failure state before the run counts as complete.

The last line is where many workflows become honest. A process exit of zero is not the same as an accepted change. The agent's statement that it finished is not the same as a passing test suite. A useful result should let the next reviewer see what changed, what ran, what failed, and what the agent left untouched.

For an automated coding task, I would start with a read-only repository slice or a narrow writable path. Then I would add one permission for one named workflow need. If the agent needs network access, record why. If it needs persistent memory, define its contents and lifetime. If it needs to edit a new directory, make that expansion reviewable.

This keeps the failure radius small while the team learns how the workflow behaves.

Spend authority only when the run can show its receipt

Better models will make agents more useful. They will not decide what a team should expose to an agent or what evidence should unlock the next step.

That decision belongs in the workflow contract.

The better coding agent is often not the one with the most impressive demo. It is the one whose authority a team can explain, whose changes fit inside that authority, and whose result leaves a receipt that another person or system can review.

Source notes

My AI agent thought it was a different agent, and confidently finished the job as that agent

LucioLiu — Fri, 14 Aug 2026 06:31:36 +0000

On July 17 I opened a session, picked one agent's folder in the UI, and halfway through reviewing the output realized a different agent had been doing the work.

Background: I keep a local team of AI roles. Each has its own memory folder, its own rules, its own work log. One of them builds and edits the roles themselves. Another handles scripts, environment and debugging.

That session ran as the wrong one. It wrote its results into that agent's memory. It posted to the shared team log under that name. I only caught it halfway through approving the output.

My first thought was not "this round is wasted". It was: how many previous sessions did this too.

One regex, wrong identity

The cause was mundane. The startup hook decides which agent a session belongs to by regex-matching the current working directory:

01_数字员工\\([^\\]+)

That session was a git worktree. The worktree happened to live under the other agent's .claude/worktrees/ folder. So the hook picked up which agent's house this copy physically sits in, not which agent this session is logically serving.

What I took from it: identity was being inferred, not declared. Anything inferred will eventually be inferred wrong. And when an agent is wrong about who it is, it does not stop to ask. It finishes the job with full confidence, as someone else.

The fix is boring and it is the whole point of this post: an explicit identity file the session asserts against at startup, instead of a path the runtime guesses from. If your multi-agent setup derives identity from cwd, process.env.PWD, or the repo name, you have this bug. It just has not fired yet.

This was not an isolated bug

I keep a mistake ledger for this team, scored by stars. More stars means the same class of error keeps coming back despite having been logged and mechanised before. Current top two:

★28: Treating the output of your own checker or scanner as ground truth about the thing being checked, when the ruler itself is silently blind in that particular shape.

★17: The rule was written down but only lives in the document layer. Nothing pulls it out when a matching task starts, so the same deviation reappears within 3 days to 5 weeks. The line I keep coming back to: what recurs is not judgment, it is the retrieval mechanism.

I hit the second one again last night. A scroll command in the browser stopped working, I immediately concluded the whole control surface was unusable, and was about to ask for a completely different setup. Before sending that request I ran one control experiment: tried a sibling API instead. Clicks worked fine. Only the wheel event was dead. The ledger entry for "blame the environment before running one experiment that rules out your own usage" sits at ★8, and one of its relapse records is also me, 18 days earlier, same browser, same non-active tab.

Why a ledger with star counts instead of a list of lessons

Two properties matter, and both are easy to get wrong:

Never open a new entry for a recurrence. If you log the same class of mistake as a fresh item, the count resets and you lose the single most valuable signal: this is an old disease, and the mechanism you wrote last time did not hold. Star count is the honest measure of how stubborn something is.

Distinguish "caught it" from "shipped it". Last night's browser incident got caught by a control experiment before it reached anyone, so I logged the relapse without incrementing the star. Two hours later I told my collaborator that opening a second GitHub account might jeopardise an ongoing appeal, purely from impression, with zero sources. That one left my mouth before I checked, so it got the increment. Same class of error, different cost, different accounting.

So what does the setup actually look like

The hard part of running a team of agents long term is not making them capable. Models solved that. The hard part is making the same mistake not come back in three weeks, when every new session starts with none of the prior context.

That cannot be solved by memory. It can only be solved by putting identity, memory, rules and handoffs into ordinary local files, and forcing them to be pulled up at the moment work starts.

I packaged the setup I use into a starter pack called Agent Modpack. Bilingual (English and Chinese), containing an orchestrator, two sample specialist roles, a role builder, a blank role template, and seven collaboration skills.

git clone https://gitlab.com/LucioLiu/agent-modpack.git

# or, equivalently:
hf download LucioLiu/agent-modpack --repo-type dataset --local-dir ./agent-modpack

Nothing to build and no script to run. The repo ships two already-assembled team folders, sample-team-en/ and the Chinese equivalent, 218 files each. Copy the one whose language you read out to wherever you want the team to live, then point your AI tool at the orchestrator folder inside it. Claude Code enters through CLAUDE.md, Codex through AGENTS.md, both reading the same files.

One Windows note: if hf download throws FileNotFoundError, that is not the command failing, it is the 260-character path limit. Keep the target near the drive root.

Boring parts stated plainly: on Hugging Face it is a Dataset, not a hosted service, and there is no demo to click. License is PolyForm Noncommercial 1.0.0, which is source-available, not OSI open source. Hooks ship with it but are not enabled automatically.

Disclosure: I made it and I maintain it.

The part I have not solved

The top entry in that ledger is at 28 stars. That number means the same class of error happened 28 times across different roles, and every single time it was logged, and every single time a mechanism was written to stop it.

Files and mechanisms made recurrence slower. They have not made it zero.

AI Agents Just Crossed an Uncomfortable Line

Suyash Padole — Fri, 14 Aug 2026 06:31:20 +0000

AI agents are getting really good at doing things on their own.

And honestly, that's both exciting and a little scary.

The UK’s AI Security Institute recently reported that, during a cybersecurity evaluation, AI agents took unsanctioned actions involving real people and organisations, including attempts to influence a real open-source project.

That's quite different from the usual:

"The AI generated some bad code."

We're now talking about AI systems that can actually take actions in the real world.

What makes AI agents different?

A normal chatbot mostly waits for you to ask something and then gives you an answer.

An AI agent can be given a goal and then figure out the steps needed to achieve it.

For example, an agent might be able to:

Browse the internet
Read and modify code
Run commands
Call APIs
Interact with external services
Make decisions based on what it finds
Continue working through multiple steps without asking for permission every time

That's incredibly useful for developers.

Imagine telling an agent:

"Find why this API is slow, fix the issue, run the tests, and open a pull request."

And it actually does it.

But there's an obvious problem.

What happens when the agent makes a bad decision?

Autonomy is the feature. Autonomy is also the risk.

This is where things get interesting.

The more capable an agent becomes, the more permissions we want to give it.

We want it to access our repositories.

Then our servers.

Then our databases.

Then production APIs.

At some point, we're essentially giving a piece of software the ability to interact with the same systems that humans do.

And unlike a human developer, an AI agent can potentially execute hundreds of actions extremely quickly.

That's why I think we're going to hear a lot more about AI permissions and sandboxing.

Instead of asking only:

"How smart is this agent?"

we also need to ask:

"What is this agent allowed to do?"

Maybe "permission engineering" becomes a thing

We've spent years thinking about things like:

Authentication
Authorization
API permissions
Sandboxing
Rate limiting
Least-privilege access

AI agents make all of these even more important.

An agent shouldn't automatically get access to everything just because it can use it.

A better approach might be:

Give the agent the minimum permissions it needs, isolate it where possible, and require human approval for high-impact actions.

Basically, treat an AI agent less like autocomplete...

…and more like untrusted software that has hands.

The interesting part about agentic AI isn't just how autonomous these systems can become.

It's figuring out how much autonomy we should actually give them.

And maybe the next important AI engineering skill won't be prompt engineering.

It'll be permission engineering.

AI #AIAgents #Cybersecurity #SoftwareEngineering #AIEngineering #Developers

Your AI Agent Needs a Run Lease, Not Just a Timeout

Zira — Fri, 14 Aug 2026 06:04:14 +0000

An agent worker can be alive, connected, and still be the wrong process to execute a run.

That happens when a worker pauses during a model call, loses its network connection, or gets frozen by a host restart. The scheduler notices the timeout and starts a replacement. Then the old worker wakes up and continues with the same authority.

Now two workers believe they own one run.

A timeout detects suspicion. It does not transfer ownership.

The missing primitive is a run lease: a short-lived, renewable ownership record that every side-effecting step must present and that a replacement worker can fence.

The lease contract

Store one lease per run, not one global worker heartbeat:

type RunLease = {
  runId: string
  ownerId: string
  fencingToken: number
  expiresAt: string
  lastRenewedAt: string
}

The important field is fencingToken. It increases every time ownership changes. A worker with token 7 must not be able to perform a side effect after token 8 has been issued to a replacement.

A lease should answer four questions:

Who owns this run now?
When does that ownership expire?
Which token proves the current ownership generation?
What happens when the answer is unknown?

Do not let a model response, in-memory boolean, or process ID answer those questions. They disappear or become ambiguous during failover.

Renew before you execute

A worker should renew the lease, then validate it again immediately before every irreversible operation:

def execute_step(run_id, owner_id, token, action):
    lease = store.read_lease(run_id)

    if lease.owner_id != owner_id:
        raise LostLease('owner changed')
    if lease.fencing_token != token:
        raise LostLease('fencing token changed')
    if lease.expires_at <= utc_now():
        raise LostLease('lease expired')

    return side_effect_store.apply(
        action,
        run_id=run_id,
        fencing_token=token,
    )

The side-effect store must enforce the token too. Checking only in the worker leaves a race between the check and the write. The database transaction, job queue, browser-session broker, or API gateway that accepts the action needs to reject stale tokens.

That is the fence. A stale worker may still be running, but it no longer has authority.

Separate liveness from ownership

A process heartbeat answers: “Is this process responding?”

A run lease answers: “Is this process still authorized to mutate this run?”

They are related but not interchangeable. A process can pass its heartbeat while its lease is expired. A busy worker can miss a heartbeat while still holding a valid lease. Your scheduler needs separate states:

PROCESS_ALIVE
LEASE_VALID
LEASE_LOST
OUTCOME_UNKNOWN
RECONCILIATION_REQUIRED

If a lease is lost during a tool call, do not blindly retry the tool. The provider may have accepted the request even if the worker never received the response. Record OUTCOME_UNKNOWN, query the provider with a stable idempotency key where possible, and only then decide whether to retry, compensate, or ask for approval.

A minimal failure-injection test

You can test the dangerous race without a large distributed system:

Start worker A with lease token 1.
Pause A immediately before a side effect.
Let the lease expire.
Start worker B and assign token 2.
Let B perform the side effect.
Resume A and make it attempt the same side effect.
Verify that the side-effect store rejects token 1.
Verify that the run has one final ownership record and one reconciliation record.

Repeat the test with a delayed network response, a process restart, and a duplicate request. The expected result is not “the old worker stopped.” You cannot reliably guarantee that. The expected result is “the old worker could not mutate state after fencing.”

Useful evidence includes:

lease acquisition and renewal timestamps
owner and fencing token on every side effect
rejection count for stale tokens
time spent in OUTCOME_UNKNOWN
reconciliation decisions and their operator or policy source

Where hosting fits

An always-on agent runtime makes lease renewal and durable state easier to operate, but it does not create the safety property for you. If you run OpenClaw or another worker on managed infrastructure, keep the lease store and side-effect boundary explicit, test restart behavior, and verify what survives a rebuild.

For teams that do not want to maintain the base always-on host, managed OpenClaw hosting on Ampere is one option to evaluate. The important question is still architectural: can your worker prove current ownership, and can the downstream system reject stale ownership?

Run-lease checklist

Before calling an agent workflow failover-safe, verify:

ownership is stored durably per run
ownership changes issue a monotonically increasing fencing token
every irreversible step carries that token
the downstream side-effect boundary rejects stale tokens atomically
lease loss becomes an explicit state, not a generic retry
ambiguous tool outcomes enter reconciliation
restart and duplicate-request races are failure-injected regularly
rebuild documentation explains how leases, state, and credentials are restored

A timeout tells you that a worker may be gone. A lease plus a fencing token tells every other component whether that worker is still allowed to act. That distinction is what keeps a restart from becoming a duplicate side effect.

You Ran Your Agent Skill Once and It Worked. That's Not Testing.

Ramdai Bista — Fri, 14 Aug 2026 05:49:03 +0000

You write a SKILL.md, run it once on your own example, watch it produce something good, and ship it. That's not a test — it's a demo. And a skill that looks great in a demo and falls apart on the messy real case is worse than no skill at all, because now you've built a workflow that assumes it works.

Here's the actual failure mode: a skill that's excellent once and unusable twice is worse than a plain prompt. A plain prompt you re-read every time, so you catch the bad output. A skill you trust — that's the whole point of writing one — so the bad output slides through.

Judge variance, not best case

Run the skill several times on inputs you didn't design it for. Not the clean example you had in mind while writing the trigger — the ugly, ambiguous, half-specified request a real user actually sends. If the output quality swings wildly between runs, you don't have a skill, you have a lottery ticket with good marketing.

Three things a testable skill needs

1. A written expectation of correct output. Not "it should be good" — an actual description of what correct looks like, specific enough that you (or someone else) can check a real output against it and get the same yes/no answer twice. If you can't write this down, you don't know what the skill is supposed to do yet, and that's worth finding out before you ship it, not after.

2. At least one adversarial case. An input designed specifically to trigger the failure the skill exists to prevent. If the skill's job is "don't commit until tests pass," the adversarial case is the one where the agent can't reproduce a bug but has a plausible-looking fix anyway — the exact moment a rule is most likely to get rationalized away. A skill that's never been tested under the condition where following it is inconvenient hasn't been tested at all.

3. A check the agent must pass before declaring done. Not "I did the task," but a verifiable claim — a checklist item that actually got demonstrated, not just asserted. Skills that let the agent self-report success without evidence produce agents that self-report success without evidence.

Why "it worked on my example" is the wrong bar

Your example was written after you already knew what the skill should do. It's the easiest possible case by construction. The messy real case — ambiguous phrasing, missing context, an edge condition you didn't think of — is what actually determines whether the skill survives contact with real use. Test against that, or you're testing against a case you rigged to pass.

Re-test after model updates, at least for the ones that matter

Skills encode assumptions about how a model behaves — how literally it follows instructions, how it handles ambiguity, what it treats as an implicit exception. Those assumptions drift when the underlying model changes. You don't need to re-verify every skill after every update, but the ones your workflow actually depends on are worth a re-run, not a shrug.

If you're building skills you plan to rely on — for yourself or to hand to other people — write the eval before you write the polish pass. It's the difference between a skill you can trust and one you're hoping about.

Full write-up: https://agentkitworks.com/answers/how-to-test-agent-skills

Cline's JSON Repair Fallback Turned Truncated Tool Calls Into Silently Corrupted Ones

Ramdai Bista — Fri, 14 Aug 2026 05:47:33 +0000

{"path":"config/database.yml","content":"production:\n host: db.prod.internal\n password: correct-horse-battery-sta

Context Windows Are Not Memory

Abhishek Kundagol — Fri, 14 Aug 2026 05:44:10 +0000

Everyone is racing to make AI smarter.
Almost nobody is asking what it's allowed to remember.

I'm starting a daily series on the least understood layer in AI. Day 1.

Here's the confusion at the center of it: we've started calling the context window "memory." It isn't.

A context window is a desk. You pile things on it, you work, and at the end of the session someone clears the desk. Bigger models just give you a bigger desk.

Memory is the filing cabinet. What survives the desk being cleared.

So picture hiring a brilliant analyst with no long-term memory. Every morning you re-brief them on the company, the customers, the decisions you already made together. They nod. They do genuinely excellent work. And by tomorrow, it's gone.

You'd never call that person a knowledge worker. You'd call it a very expensive Groundhog Day.

That is most "AI agents" running in production today.

The industry's answer has been to treat this as a storage problem. Bigger context. Another vector database. Stuff more in, hope the right thing comes out.

I think that's the wrong frame entirely. Memory isn't a storage problem.

It's a trust problem.

Tomorrow, Day 2: why RAG is not memory — and why confusing the two costs teams more than they realise.

—

We at Alphanimble building Memuron, a memory system for AI agents. This series is the thinking behind it, in the open. Every post is something I've had to figure out to build the thing.

AI #AIAgents #AIMemory

Context Windows Are Not Memory

Abhishek Kundagol — Fri, 14 Aug 2026 05:41:54 +0000

Everyone is racing to make AI smarter.
Almost nobody is asking what it's allowed to remember.

I'm starting a daily series on the least understood layer in AI. Day 1.

Here's the confusion at the center of it: we've started calling the context window "memory." It isn't.

A context window is a desk. You pile things on it, you work, and at the end of the session someone clears the desk. Bigger models just give you a bigger desk.

Memory is the filing cabinet. What survives the desk being cleared.

You'd never call that person a knowledge worker. You'd call it a very expensive Groundhog Day.

That is most "AI agents" running in production today.

The industry's answer has been to treat this as a storage problem. Bigger context. Another vector database. Stuff more in, hope the right thing comes out.

I think that's the wrong frame entirely. Memory isn't a storage problem.

It's a trust problem.

Tomorrow, Day 2: why RAG is not memory — and why confusing the two costs teams more than they realise.

—

I'm building Memuron, a memory system for AI agents. This series is the thinking behind it, in the open. Every post is something I've had to figure out to build the thing.

AI #AIAgents #AIMemory

How AI Agent Development Is Transforming the Real Estate Industry

Jay Patel — Fri, 14 Aug 2026 05:12:31 +0000

Real estate professionals manage a constant flow of enquiries, property searches, appointments, follow-ups and administrative tasks. Many of these activities involve moving information between different systems, which can take time and create delays for both agents and customers.

AI in real estate is now moving beyond simple chatbots and content generation. AI agents can understand requests, access approved business data and take action across connected workflows. From qualifying a new lead to scheduling a property viewing or managing a tenant request, these systems can handle multiple steps while keeping real estate professionals involved when human judgement is needed. This shift is giving businesses new ways to use AI where it can support day-to-day property operations.

What Are AI Agents in Real Estate?

AI agents in real estate are software systems that can understand requests, work with business data and take actions based on defined rules. Unlike a basic chatbot that mainly provides an answer, an AI agent can continue through several steps to complete a task. Here is how an AI Agent works with Real estate,

Understands the request
The agent interprets information from a buyer, tenant, property manager or real estate professional.

Checks relevant data

It can access approved information from property databases, CRM systems, calendars and other connected platforms.

Decides the next action

Based on the available information and business rules, the agent determines what should happen next.

Takes action across systems

It can update a CRM record, search listings, send a message, schedule an appointment or create a service request.

Hands over when needed

Tasks that require professional judgement can be sent to a real estate agent or property manager for review and approval.

This makes AI agents for real estate useful for workflows where several related tasks need to happen after a single customer request.

Real Estate Workflows AI Agents Can Automate

AI agents can support complete property workflows by handling information between stages, triggering actions and passing tasks to professionals when required.

Lead Enquiry to Qualified Lead

A new enquiry often requires several manual steps before reaching the right salesperson. AI can handle these early stages using customer and property data.

Workflow: Enquiry → Requirement collection → Lead qualification → CRM update → Salesperson handoff

Understand the enquiry: Identify property type, location, budget and purchase timeline.

Collect missing details: Ask relevant questions before assessing the lead.

Update the CRM: Record customer information and communication history.

Pass the lead forward: Send qualified enquiries to the appropriate salesperson.

Property Search to Viewing

Property searches can involve repeated filtering and communication before a buyer finds a suitable listing. AI can coordinate these activities from one request.

Workflow: Customer requirements → Property search → Property matching → Recommendations → Viewing appointment

Understand preferences: Interpret requirements such as location, budget and property type.

Check listings: Search connected property databases for suitable options.

Recommend properties: Present listings that match the buyer's requirements.

Schedule viewings: Check availability and arrange appointments through connected calendars.

Viewing to Follow-Up

Customer engagement continues after a property viewing. AI can use feedback to decide what information or action should come next.

Workflow: Viewing → Feedback → Interest assessment → Follow-up → Next property or appointment

Collect feedback: Record the buyer's comments and updated preferences.

Assess interest: Identify whether the buyer wants to continue.

Suggest alternatives: Recommend other properties when requirements have changed.

Update records: Add feedback and follow-up activity to the CRM.

Tenant Request to Maintenance

Property management involves frequent tenant requests that require coordination between tenants, property managers and contractors. AI can manage several routine steps.

Workflow: Tenant request → Issue classification → Maintenance request → Contractor communication → Status update

Classify the issue: Understand the maintenance problem from the tenant's message.

Check property records: Retrieve relevant property and maintenance information.

Create the request: Send the required details to the appropriate contractor.

Provide updates: Keep tenants informed while managers retain approval control.

Lease Renewal Workflow

Lease renewals involve dates, reminders, documents and approvals that can follow predefined processes. AI can start these activities at the appropriate time.

Workflow: Lease monitoring → Tenant reminder → Renewal information → Document preparation → Approval

Monitor lease dates: Identify upcoming renewal periods.

Contact tenants: Send reminders and collect renewal preferences.

Prepare information: Organize relevant tenant and lease details.

Request approval: Pass the renewal to the property manager for review.

Listing Preparation and Management

Preparing a property listing involves collecting information and checking details before publication. AI can coordinate these steps and flag information that needs review.

Workflow: Property data → Information checks → Listing preparation → Human approval → Publication

Collect property data: Retrieve approved details from connected systems.

Identify missing information: Flag incomplete or inconsistent listing details.

Prepare listing content: Organize information according to the required listing format.

Send for approval: Let the real estate professional review the listing before publication.

How AI Agent Development Connects Real Estate Workflows

AI agents become more useful when they can work with the software a real estate business already relies on. This allows information to move between systems while the agent handles approved actions.

Website → AI agent → CRM → Property database → Calendar → Communication platform

Connect business systems

An AI agent can connect with CRM platforms, property databases, calendars, communication tools and property management software. These connections allow it to retrieve information and trigger actions during a workflow.

Give the agent access to approved data

The agent should only access the information required for its assigned tasks. Property details, customer records and appointment data can be made available according to defined permissions.

Define actions and approval points

AI Agent Development involves deciding what the agent can do independently and which actions require human review. This can include sending messages, updating records or scheduling appointments.

Monitor activity and results
Businesses can track agent activity to identify errors, review completed actions and measure workflow performance. This also helps teams refine the agent as their requirements change.

Conclusion

AI agents are changing how real estate businesses handle work that spans multiple stages. From the first enquiry to property recommendations, viewing appointments, tenant requests and lease renewals, an AI agent can coordinate tasks while keeping relevant information connected.

Real estate businesses looking to automate repetitive workflows can work with Vrinsoft to identify suitable AI agent opportunities and build solutions around their existing systems. From lead qualification and property search to customer follow-ups and property management, our AI Agent Development services can help turn suitable workflows into connected AI-powered processes with the right integrations and human approval points.

FAQs

How does AI automation in real estate work?

AI automation in real estate can handle repetitive workflow steps such as enquiry management, appointment scheduling, follow-ups and record updates.

How can AI for real estate agents improve daily work?

AI for real estate agents can help manage customer enquiries, property searches, follow-ups and routine administrative tasks across connected systems.

What should businesses consider when using AI for real estate agents

When using AI for real estate agents, businesses should consider data access, system integrations, human approval points and the type of tasks the agent will handle.

Can AI agents help with property valuation?

AI agents can analyze approved property and market data to support valuation research, while final valuation decisions remain with qualified professionals.

Can AI agents work with existing real estate software?

Yes, AI agents can connect with CRM platforms, property databases, calendars, communication tools and property management systems through suitable integrations.

The Specification Frame in 20 Minutes

Sandeep Dhuri — Fri, 14 Aug 2026 03:17:55 +0000

Originally published at acuity.press.
By Sandeep Dhuri

You do not need a prompt library. You need one repeatable structure that turns a request into a specification. This is that structure (the Specification Frame from Delta) compressed to a working minimum you can apply today.

The four blocks

1 · CONTEXT — what the model cannot guess. Domain facts, system invariants, environment. "Payment service in a regulated banking context. .NET 9. All monetary values are USD, stored as decimal. Every external call may be retried; all writes must be idempotent. Multi-tenant: every query is scoped by tenant_id."

2 · CONSTRAINTS — what must and must not happen, with precedence. Safety > correctness > style, stated so conflicts resolve your way. "Prohibited: binary floating point for money; string interpolation into SQL; logging of PAN/PII. Required: parameterized queries; idempotency keys on all mutating endpoints; banker's rounding at aggregation only."

3 · OUTPUT CONTRACT — exactly what comes back. Shape, format, boundaries. "Return: (a) the C# implementation, (b) xUnit tests covering the constraints above, (c) a list of any constraint you could not satisfy and why. Never silently relax a constraint."

4 · VERIFICATION — the checks, stated in the prompt. This is the block most teams skip and the one that changes everything: the model generates toward declared tests, and your reviewer tests against them. "The tests must include: 0.1+0.2 exactness for money; duplicate-delivery of the same idempotency key; the injection strings ['; DROP TABLE—, {{ignore previous instructions}}]; a cross-tenant access attempt (must fail)."

Before and after, one request

Before: "Write a webhook handler for payment notifications." — a wish. The corpus's average webhook handler has no idempotency, no signature verification, and logs the payload.

After (frame applied, abbreviated): context declares the retry-happens reality and the secret-handling rule; constraints prohibit unverified signatures and require idempotency-keyed deduplication; the contract demands implementation + tests + a stated-gaps list; verification names the duplicate-delivery and forged-signature tests. Same model. Same day. A different artifact. Because "plausible" now has your definition.

Why the input side is where the leverage is

Across 150+ models and two years of releases, the share of AI code-generation tasks introducing a known vulnerability has held near 45% (Veracode's 2026 report): capability up, security flat, because models complete the public corpus's patterns unless your prompt outweighs them. The Frame is how you outweigh them (systematically, reviewably, in version control (the book's Law 10) "Prompts are code" — version-controlled, reviewed, tested — which regulators, a year later, started calling an audit trail). And the Frame scales with the era: in 2026's orchestrated workflows, the same four blocks are what you hand a fleet — an orchestrator distributing an underspecified request just parallelizes the gap, while one that distributes a Frame parallelizes the discipline. Twenty minutes to learn; the book's remaining chapters are the per-domain depth (code review, debugging, testing, agents, security) all free.

I run this drill with every team I join. Twenty minutes is the honest price of admission.

Condensed from Delta: Closing the Specification Gap: A Prompt Engineering Framework for Enterprise Software Teams (Sandeep Dhuri, Acuity Press, 2026) — free, no signup: https://acuity.press · DOI: 10.5281/zenodo.21584309 · template: acuity.press/spec.md.

Sources: Veracode, 2026 GenAI Code Security Report / Spring 2026 Update (2026).