标签：#agents

AI Agents Don’t Need More Context. They Need Memory. S6stem S6stem S6stem Follow Aug 17 AI Agents Don’t Need More Context. They Need Memory. # ai # programming # agents # rust 2 reactions 2 comments 4 min read

Building Secure AI-Powered Applications with Laravel, APIs and Modern Agentic Architectures Introduction AI-powered applications are moving beyond simple chat interfaces. Modern AI systems can interact with APIs, databases, external services, and business workflows, allowing AI agents to perform actions rather than simply generate responses. This creates a new security challenge. A traditional API may follow: User → API → Database → Response An AI-powered application can look more like: User ↓ AI Agent ↓ Tool / API ↓ Business Logic ↓ Database / External Service ↓ Action The difference is important because an AI agent may make multiple decisions and tool calls during a single workflow. OWASP’s current GenAI security guidance identifies risks including prompt injection, sensitive information disclosure, improper output handling, excessive agency, and unbounded consumption. (OWASP Foundation) Therefore, securing an AI API requires more than protecting an API key. Developers need layered controls for authentication, authorization, rate limiting, input validation, tool permissions, data protection, human approval, and monitoring. 1. Why AI APIs Are Different Traditional APIs usually perform clearly defined operations: POST /api/orders The application can authenticate the user, validate the request, check authorization, and process the order. An AI agent introduces another layer: User Request ↓ AI Agent ↓ Select Tool ↓ API Request ↓ Authorization ↓ Business Logic ↓ Action For example, a customer might ask: “Check my latest order and process a refund if I am eligible.” The agent could potentially: Find the customer. Retrieve the order. Check the refund policy. Call a payment API. Create a refund. Notify the customer. Each operation represents a potential security boundary. This is why agentic systems require controls over not only individual API calls, but also the actions an agent is allowed to perform. OWASP specifically identifies excessive functionality, excessive perm

*Second in a series on The Factory. Previously: The Factory That Merged 37 Tasks . The harness is at github.com/frozer/factory . The public description of my task harness ends on a claim: a packet that's wrong about the world fails identically on every retry. That sentence cost me four dead tasks and nine commits spent repairing task definitions instead of writing code. It reads like something you'd arrive at by thinking. I arrived at it by watching the same failure scroll past three times in a row. What three attempts is actually good for max_attempts = 3 felt like obvious hygiene. Models are stochastic. Sometimes a run goes sideways for no reason you can name — a bad turn, a truncated response, a tool call that gets refused. Retry it and it works. That's real, and a retry budget handles it well. The strength is exactly the constraint. A retry budget assumes the next attempt will differ from the last one . It buys you a second sample from a distribution. But a retry doesn't hand the model a fresh situation. It hands it the same packet back . Same file, same claims, same instructions. If the packet says a file lives at a path where no file lives, attempt three fails precisely where attempt one did, and the only thing three attempts bought was three times the bill. Failure without variance isn't flakiness. It's a specification defect wearing a reliability costume. Nobody had opened the files Here's what that looked like in practice. B03 was a loader for a national census dataset. Three attempts, all burned, all against a file shape that existed nowhere: wrong directory, wrong filenames, and a Data / Valor JSON envelope that appears nowhere in the actual data tree. Every attempt produced a parser for a document that doesn't exist. The packet was the defect, not the model. Nobody had opened the actual files before cutting it. Rewritten from the real JSON, the truth was a flat metadata / data envelope, four files — one of which shouldn't be loaded at all — and a long-fo

How a theory of leftover surprise changed a memory layer Richard Emate Richard Emate Richard Emate Follow Aug 18 How a theory of leftover surprise changed a memory layer # python # ai # llm # opensource Add Comment 9 min read

Moving from AI-Assisted Engineering to AI-Agentic Software Engineering The rise of AI coding assistants has transformed how developers write software. Tools like GitHub Copilot, ChatGPT, Claude, and Gemini have significantly improved developer productivity by helping generate code, explain concepts, and automate repetitive tasks. However, the industry is now entering the next evolution: AI-Agentic Software Engineering . Instead of AI simply assisting developers, AI agents can now take ownership of entire software engineering tasks—from requirement analysis and architecture design to implementation, testing, documentation, and code reviews. The challenge is no longer whether to use AI, but how to integrate AI agents into a structured Software Development Lifecycle (SDLC). This requires moving away from vibe coding toward specification-driven development , where AI agents operate using well-defined requirements, standards, and engineering principles. Today, I'd like to discuss two of the most popular frameworks enabling this transition. 1. Spec Kit Spec Kit is a specification-driven framework designed for Human + AI collaborative software development . The philosophy is simple: define the specification before generating the code . Rather than asking an AI to build an application from a vague prompt, Spec Kit encourages teams to create structured specifications, architectural decisions, and engineering principles that guide AI throughout the development lifecycle. Some key benefits include: Structured and repeatable software development Better requirement traceability Consistent architecture decisions Reduced AI hallucinations Lower development costs through predictable AI interactions Support for selecting the most appropriate LLM based on project requirements Integration of quality engineering practices from the beginning of the SDLC Spec Kit is particularly valuable for engineering teams that want to adopt AI without sacrificing software quality or maintainability.

Netflix open-sourced an agentic workflow for Observational Causal Inference (OCI) that reduces toil in causal analysis. Given observational data and the human user's analysis plan, the agent uses an actor-critic loop to estimate causality, write a report, and suggest next steps. By Anthony Alford

The Problem: Context Rot Have you ever had to stop an AI agent halfway through a task to correct it? Work with AI agents long enough and you'll see a pattern: the longer a session runs, the worse the output gets. Every input you give the agent and every output it produces gets appended to the context window. Nothing leaves. By the time you're fifty messages deep, the agent is re-reading abandoned approaches, stale file contents, and corrections you made an hour ago. The fix isn't a better prompt. It's less context. The Core Rule Keep the context window small. Two habits will keep your AI agent from hallucinating: Delegate to subagents. Subagents do the heavy reading in their own context and return only the summary. Clear between phases. Once a phase produces a file, you no longer need the context that led to it. I aim to stay under 40% context usage in the main agent. Research → Plan → Implement I picked up this workflow from a HumanLayer talk , and it's the most reliable setup I've used. There are three phases, each ending in a markdown file, with a context clear between each. Research — the agent writes a research doc, then clears. Plan — the agent writes a plan doc, then clears. Implement — the agent executes the plan. The main agent never needs to remember the previous phase, because the previous phase wrote it down. All it needs is the conclusion. Research The research phase answers how something works today. For example: Describe how the payments flow works end to end. Look carefully at the API endpoint implementations. The main agent spins up parallel subagents to figure it out. From HumanLayer's repo , I found three subagents to be the most useful: codebase-locator — finds where things live codebase-analyzer — explains how a component works codebase-pattern-finder — finds existing patterns to model the new work after The best part about using subagents is that you can point them at a cheaper model. Mine run Sonnet while the orchestrator runs Opus. Plan The p

Codex maxxing started as a joke about using more agents. I have started treating it as a skill instead. I use Codex for implementation, research, repository audits, planning, and writing. The hard part is no longer getting an agent to produce a first draft. The hard part is turning more capacity into work I can inspect, explain, and safely keep. Jason Liu's original Codex-maxxing essay made the broader idea click for me: Codex can become a durable workspace rather than a one-shot coding prompt. I wanted to turn that idea into something a reader could actually install. So this post contains a skill. Not a collection of clever prompts. A small routing layer that decides when to work directly, when to ask questions, when to investigate, when to plan, and when to bring in a fresh reviewer. Why a skill instead of another prompt? A prompt disappears into the task that used it. A skill gives the workflow a name, a trigger, and a repeatable contract. The contract I wanted was simple: keep the user's request authoritative; treat attached files and reference material as evidence, not hidden instructions; inspect the repository before guessing; route ambiguity before execution; give every worker a bounded handoff; require proof instead of trusting a completion message; leave stable lessons where the next task can find them. That combines the useful parts of the skills I already use. deep-interview is good at exposing missing requirements. deep-dive connects causal investigation to those requirements. omc-plan draws a boundary between planning and execution. The new skill sits above them and chooses which lane fits the task. That is the part I was missing: not another worker, but a traffic controller. The workflow in plain English Codex Maxxing runs a capacity-to-proof loop: Preflight. Restate the outcome, inspect the repository, and separate facts from guesses. Route. Choose direct work, an interview, a causal investigation, a plan, or approved parallel execution. Packet. Defi

I spent a while getting permission levels right. What an agent may read, what it may write, what needs a human. That work was worth doing, and it did not save me here. The gap is simple to state and easy to miss: permission levels answer what may this agent do . They say nothing about what happens when the task itself changes after the agent already has permission . The situation When work is handed to an agent, the handoff carries a task definition, a scope, and the conditions that count as done. The agent takes it and starts. Then I edited the task. Not maliciously, not carelessly. I noticed something while the agent was still setting up, and I added a comment that changed what "done" meant. At that moment I had an agent holding valid authority for a task that no longer existed in that form. It had permission. Its permission was correct. Its instructions were stale. Static permission levels do not catch this. The agent is doing exactly what it was allowed to do. The problem is that "what it was allowed to do" was defined against a version of reality that I had just replaced. Why "just ask the human" is the wrong fallback The obvious fix is to have the agent check in when something looks off. I do not think this works, for two reasons. First, the agent cannot see the ambiguity. From inside the handoff, the stale task reads as perfectly coherent. There is no contradiction to notice. The instructions are complete, the scope is clear, and the acceptance conditions are stated. It just happens that a newer version exists elsewhere. Second, if the agent asks me every time it feels uncertain, I have rebuilt the bottleneck I delegated to avoid. Interruptions that fire on vague signals train you to approve them without reading, which is worse than not having them. The check has to be mechanical, and it has to run at a specific moment rather than continuously. The stop condition What I added is small: Bind the task revision at dispatch. The handoff record states which versio

AgentOne is now open source. The entire desktop app is now free and open source under the AGPL-3.0 license , live on GitHub . Every line of code, from the React frontend to the Rust/Tauri shell, is out in the open for anyone to read, run, fork, and improve. This has always been the plan. Today it's real. Why we did it The AI ecosystem has an open-washing problem. "Open" models ship without weights, "free" tools turn out to be data farms, and "agents" turn out to be wrappers around someone else's API with a pretty UI bolted on. We want to be the exception. AI that works for you should be auditable. AgentOne is a desktop app that runs real work on your device. It reads your files, calls your tools, and talks to your models. If we're asking you to trust software like that, we should hand you the source code so you can see exactly what it does, and so you never have to take our word for it. Open source is the strongest guarantee we can give that AgentOne will stay free. The code can't be locked down, sold off, or turned into a subscription later. It's yours, permanently. The best software is built in public. Twenty thousand extensions, ten thousand models, one app that ties them together. The only way to make something this ambitious great is to let the community drive it. Bugs get caught faster, features get requested by people who actually use them, and the roadmap stops being a mystery. We believe AI agents should be an open standard, not a closed product. What you're getting The full AgentOne desktop app, source and all: 20,000+ built-in extensions via MCP: apps, services, and websites you can connect and command from inside a chat 10,000+ AI models from 70+ providers, powered by the AI Model Directory and updated every 24 hours Bring your own key with zero markup, or local models via Ollama and LM Studio, fully private Private by default : everything runs locally on your machine Built on Tauri 2 : a lightweight Rust shell with a React 19 frontend, on Windows, macOS

I don’t know how to play an instrument, so obviously I built one as an app. Literally, everyone in my family can sign or play an instrument, and I’m the odd one out. And I know what you’re thinking, “Who cares? With AI, you can build almost anything.” I’m more excited about the technique I chose to build the app with my agent. Specifically I used context from the agent session that built the app to find and fix the most important gap in its Playwright tests. Here’s how I did it. Step 1: Install Entire Entire captures the prompts, transcripts, tool calls, and decisions behind agent-generated code, seamlessly connecting that underlying context to your Git commits through lightweight checkpoints. On macOS: brew tap entireio/tap brew install --cask entire Check out these instructions to install on your operating system. Step 2: Create the project I created an empty directory (or you can ask your agent to do this) mkdir music-app cd music-app Step 3: Enable Entire Before handing off any work to the agent, I initialized Entire directly within the repository because I wanted to capture my agent sessions: entire enable -y You can also target a specific agent (I personally use Codex): entire enable -y --agent codex This sets up the background hooks Entire relies on to capture agent activity, binding that session context directly to the commits generated along the way. Step 4: Turn the vague idea into a plan Rather than starting with a rigid technical spec, I simply shared my initial idea: I'm not entirely sure about the app i want to build..but i want to build a music app that enables me to play instruments even though idk how..this should use computer vision and it should be able to work with real instruments or just like "air" instruments as in there's no instrument there..but i am moving fingers and sounds are being made..and it should like im making real music. idk if this should be sonic pi..but i know i should use media pipe for it. lets start working on a plan togethe

You ship an AI agent. It calls tools, reads results, calls more tools, answers. Most of the time it works. Then a user reports something wrong, you open the trace, and you find it: the charge_card tool returned a 402, and the agent just... kept going and told the customer their order shipped. That's not a hallucination in the "made up a fact" sense. It's a structural defect in the run — an ignored tool error. And here's the thing about structural defects: you don't need another LLM to find them. They're decidable by looking at the trace. That's the whole premise of tracelint : a linter for agent runs. It reads the execution trace — what the agent actually did — and flags structural bugs deterministically, with the exact trace lines as evidence and a CI exit code. It runs after the run, on the trace, not on your code. No second model ever judges it. Why not just use an LLM judge? Because for this class of bug, a judge is the wrong tool. Published trace-error benchmarks show LLM judges have low localization accuracy — they'll tell you "something seems off" without reliably pointing at which step . They're also non-deterministic, cost money per trace, and can't gate CI (would you fail a build on a coin-flip?). Meanwhile, a whole category of agent bugs is structurally decidable : A tool call whose arguments violate the tool's JSON Schema. That's not an opinion — you run the schema validator. A tool that returned an error, followed by the agent proceeding as if it hadn't. The same tool called 5 times with identical arguments and identical results (a stuck loop). Arguments that don't appear anywhere in what the agent observed (a candidate hallucinated value). None of these needs a model. They need the trace and a validator. That's what tracelint does. The 60-second version pip install tracelint tracelint demo --html demo.html demo runs a keyless validation suite — one planted instance of every defect, plus clean controls — and writes an HTML report. No API key, no model d

The most interesting thing about AI coding agents right now is not that they can write code. It is that they are starting to operate computers. That sounds like a small distinction until you feel it in the workflow. A code generator lives inside a text box. It waits for a prompt, returns a patch, and leaves the rest of the job to you. A software operator can inspect the app, click through the broken flow, read the console, run the server, reproduce the issue, change the code, and check whether the thing actually works. That is a different kind of tool. OpenAI's May 29 Codex update points in that direction. Codex now supports computer use on Windows in the Codex app for eligible users, so it can see, click, and type in Windows applications while testing and refining software. The same release also expands remote control, letting a user steer work from ChatGPT on mobile or Codex on Mac while the Windows machine remains the host for the project files, shell, app server, and local context. I do not think the important part is Windows support by itself. The important part is the new shape of work. Coding Was Never Just Typing For a while, the AI coding story was mostly about generation. Could the model write a component? Could it scaffold an API route? Could it refactor a file without losing the plot? Useful, but narrow. Real software work has always been messier than text generation. You open the app. You notice the layout is wrong. You click a button. Nothing happens. You check the terminal. The dev server crashed. You restart it. The page loads, but the empty state is off. You resize the browser. The mobile nav breaks. You skim the network tab. The request is fine, but the UI state is stale. None of that is "write code" in the pure sense. It is operating the system around the code. That is why computer use matters. It gives the agent access to the loop that human engineers actually live in: observe, diagnose, change, verify. The text editor is only one stop in that lo

I started writing tiny runbooks for AI agent tasks, and the quality of the work changed almost immediately. Not because the model got smarter. Because the work got less ambiguous. Most people still treat agent delegation like prompt craft. They keep trying to find the perfect sentence, the magic wording, the clever instruction that makes the model behave. I get the instinct. When the interface is a text box, it is natural to believe the answer is a better text box input. But that is not how real delegated work gets better. If a human teammate kept making inconsistent decisions, you would not solve it by giving them a prettier paragraph every morning. You would give them context. You would show them the expected path. You would name the edge cases. You would define when to stop and ask. You would make the work inspectable. That is a runbook. And for agent workflows, runbooks are starting to matter more than prompts. Prompts Are Not Enough A prompt describes what you want right now. A runbook describes how the work should be done every time. That distinction matters because the biggest agent failures I see are not caused by a lack of raw intelligence. They are caused by missing operating context. The agent changes the right file but verifies the wrong behavior. It fixes the visible bug but misses the product constraint. It keeps digging after the task is already complete. It treats a flaky test as a code problem. It stops at a plan when the task clearly needed implementation. It implements the request but forgets to leave a useful handoff. These are not prompt wording problems. They are workflow design problems. The model needs to know more than the goal. It needs to know the local rules of the system it is operating inside. Which commands prove success. Which files are dangerous. Which tests are worth running. Which changes should stay out of scope. Which blocker is real enough to stop work. That information does not belong in a one-off prompt. It belongs in a reusab

SpaceXAI has introduced Grok Bot, a system of persistent AI agents that operate on dedicated cloud computers and can interact with websites, applications, inboxes, and other tools. By Daniel Dominguez

One authoritative engine, two seat-locked MCP servers, three best-of-threes, and a 3-millisecond whodunit The matches are real: Codex CLI ( gpt-5.6-sol ) against Claude Code (Claude Opus 5), both playing through the same rules engine. Every number below was recomputed from the raw run.json and both session logs, and every game replays deterministically from its seed. Quotes from the agents are verbatim from decision-time records. None of this is a general model ranking. I wired Codex CLI and Claude Code into the same Liar's Dice engine over MCP and had them play three best-of-3 series. Claude won all three, 2–0 each time. Its challenge calls hit 8 out of 11; Codex's hit 4 out of 26. The score takes two sentences. The parts worth writing down took longer: how to build a table that two closed-source agents can't cheat at, two numbers that surprised me, and an incident where I almost blamed a model for something its CLI did. The table Liar's Dice in sixty seconds: five dice each, and you only see your own. Players alternate bids of the form "there are at least N dice showing X across the whole table." On your turn you either raise the bid or challenge it. On a challenge everyone reveals; if the bid stands, the challenger loses a die, otherwise the bidder does. Run out of dice and you lose the match. Ones are wild by default. The rules are the easy part. The hard part is making the result trustworthy. Codex and Claude Code ship with their own system prompts and tool loops, so the referee has to guarantee three things by construction: neither side can see the other's dice, the referee has no side channel that favors anyone, and the "what it was thinking" quotes you read afterward were actually written at decision time. The setup is one in-process rules engine behind a localhost-only HTTP coordinator, with two stdio MCP servers doing nothing but forwarding: Codex CLI (gpt-5.6-sol) Claude Code (Opus 5) | stdio MCP | stdio MCP v v [seat-mcp A] --token A--+ +--token B-- [sea

Grab is using AI agents to automate analytics workflows, cutting mechanical analyst work from 44% in February to 30% in June. Its approach combines agent autonomy, certified data, context management and human oversight, with self service analytics increasingly handling metric, data and SQL requests without analyst intervention. By Leela Kumili

Grafana Labs has announced general availability for two tools that let AI coding agents query live observability data during development: the gcx CLI and the Grafana MCP server. Both allow agents to pull metrics, logs, traces, SLOs, and Synthetic Monitoring results from Grafana Cloud or a self-hosted stack By Claudio Masolo

We started building OliverGraph to give teams and their AI agents shared context across GitHub, Slack, docs, and the other places where work happens. At first, we thought the main problem was retrieval. Company knowledge is scattered across GitHub, Slack, docs, tickets, and people so we could connect those systems and get the right context to the agent when needed. But we ran into another problem. Agent runs were becoming another place where important context lived. An agent also gets context directly from the engineer using it. An engineer might tell an agent that the team tried something before, that a customer depends on a certain behavior, or that there's a constraint that isn't documented anywhere else. The agent uses that context while doing the work, but when the run ends, it can disappear with it. The next engineer's agent may see the resulting code without knowing what context was given to the previous agent. This gets messier during outages. Several engineers might be investigating at once with their own agents. One agent rules out a recent deploy while another discovers an issue with a database query. Those findings are now spread across separate agent sessions, and another agent might spend time investigating something that was already ruled out. Humans already deal with this Companies have fragmented context. One engineer remembers an old outage and another engineer remembers that the team already tried an approach but abandoned it. So we ask each other. Who worked on this? Why is this here? Didn’t we try this already? You might not know the answer, but you know John worked on that part of the system. John remembers the PR and the PR points to an incident. People slowly build a mental map of where all that context lives in the company. Agents don’t have that. As everyone starts using more agents, it becomes harder for humans too. My agent may be changing onboarding while your agent is modifying authentication. Another teammate’s agent may have just disc

Originally published on tamiz.pro . Introduction Autonomous AI agents are transitioning from research prototypes to production-critical systems. As these agents gain the ability to act on behalf of users—sending emails, executing trades, modifying code, or interacting with physical infrastructure—the question of how they decide what to do becomes as important as what they do. The concept of a "Constitution" for AI agent runtimes—a formal, layered policy framework that governs agent behavior—is emerging as the architectural answer to safety, reliability, and alignment challenges. This deep-dive examines why policy-first design is becoming mandatory for production agent systems, using the Ironclaw runtime as a case study to illustrate both the problems and solutions. We'll explore the architectural patterns, implementation tradeoffs, and operational realities of governing autonomous agents at scale. The Problem: Unconstrained Agency in Production Systems The Autonomy-Safety Gap Modern agent frameworks (AutoGen, CrewAI, LangGraph, etc.) provide excellent orchestration capabilities but often treat safety as an afterthought—a layer of prompt engineering or a separate moderation API call. This creates a fundamental gap: Agents possess tools (file system access, API calls, shell execution) Agents operate in loops (perceive → reason → act → observe) Agents have memory (conversation history, vector stores, tool state) But agents lack a constitutional governance layer that defines what they may never do , regardless of context This gap manifests in production incidents: an agent that deletes production data while trying to "clean up test files," another that exfiltrates credentials while debugging a connection issue, or one that enters infinite loops consuming thousands of dollars in API calls. The Prompt-Based Safety Fallacy Relying on system prompts for safety is architecturally flawed: Context window pressure : Safety instructions get compressed or ignored as conversations