标签：#agents

I watched an AI agent send 200 emails to the wrong recipients because I forgot one validation check. The emails were well written. The offers were real. The recipients were just... not our leads. That was early. I learned fast. Every agent I build now has three layers of guardrails before it touches a database or an API. Here's exactly what those layers look like and why they're non-negotiable for production. Input Validation: Your Prompt Is Not a Schema The first mistake people make is trusting the LLM to produce valid output. It won't. Not reliably. I've seen GPT-4 return a JSON key called "emial" instead of "email" in a critical pipeline. One typo, and the whole record is garbage. The fix is a strict validation layer that runs before any data reaches your system. In my AI resume tailor, I use a JSON schema with conditional presence flags. Every field that must be real has a has_* boolean guard. If the LLM tries to fabricate a phone number, the schema rejects it. const resumeSchema = z . object ({ contact : z . object ({ email : z . string (). email (), phone : z . string (). optional (), has_phone : z . boolean () }). refine ( data => { // If phone is present, the guard must be true return data . phone ? data . has_phone : ! data . has_phone }, " Phone number present but has_phone flag is false " ) }) This pattern catches hallucinations before they corrupt your database. The schema is the contract. The LLM is just a suggestion engine. Permission Scoping: Give Agents the Minimum They Need An agent should never have write access to tables it doesn't need. That sounds obvious, but I've seen production systems where a job description rewriting agent had full CRUD access to the user table. When I built the LLM scoring pipeline for a job board platform, I created separate database roles. The scoring agent only had SELECT on the job listings table and INSERT on a scoring results table. It never touched users, applications, or configuration. Even if the prompt was hijack

When I first wrote about NutriAgent in November 2025, it was a full application. It had a Python backend, a web interface, a Telegram bot, user accounts, Google OAuth, Supabase, and a Google Sheets integration. Recently, I reproduced its core workflow as a skill for my personal AI agent. It took around 15 minutes and two prompts. I didn't build another backend, deploy a service, or implement OAuth again. I explained how I wanted the workflow to behave, tested it, and watched a new row appear in my nutrition spreadsheet. The original application wasn't a mistake. It was how I could deliver that experience with the tools available at the time. Eight months later, the starting point had changed. Eight Months Ago, This Was an App I built NutriAgent because I wanted to track calories and protein without trapping my data inside a nutrition app. I wanted the raw records in a spreadsheet I controlled, where I could create my own reports and eventually connect nutrition with my training data. The first version was a personal n8n workflow. It worked for me, but when a friend wanted to try it, I realized that everything was tied to my accounts. To make it reusable, I rebuilt it in Python and added the parts a real multi-user product needed: authentication, storage, a web interface, Telegram, Google OAuth, conversation history, and account linking. I've already told that story in I Ditched MyFitnessPal and Built an AI Agent to Track My Food , and later wrote about what broke after I used it every day for a month . This article starts after that version. My Gaming PC Became an Agent Box I had a modest gaming PC at home with 16 GB of RAM and a 1 TB drive. Using it through Windows, WSL, and remote desktop from my Mac felt awkward, so I installed Linux and turned it into a remote box for running agents. I'll write about that setup separately. I moved Hermes there from a VPS. Hermes is the personal agent I now run on that machine. It can load reusable skills and use tools connected

Everyone's talking about AI agents right now, but most tutorials stop at "call an LLM in a loop." If...

I used to deride the idea of an AI assistant from the moment they entered the picture (after seeing all the different *Claw variants). Why would regular people like me need an assistant? The best use case I had heard was: "Oh! It helps us decide whether I or my partner should drive the kids today!" Solving that sounded like a silly problem for an AI assistant to handle. Again, I didn't know any better because I didn't have that problem. I thought I could handle one-off tasks with just an AI subscription. What else was there? I only found the answer once I had a specific use case for it. I attended a business event, talked to a dozen people, and collected several business cards. I wanted to send each person a personalized email thanking them and continuing our conversation. If I were to do this manually, the process would look like this: open the email client, manually type in each email address from the business cards, ensure I typed everything correctly, compose my message, and again, make sure I didn't press "send" prematurely. Just thinking about it felt tedious. That is when the idea of an assistant started making sense. I fire up my coding agent(not a *Claw still), I take a single photo of all the business cards together. I ask the it to extract the names and email addresses. Then, I ask it to loop through the list and ask me what I want to send to each person. It creates drafts(which I still manually review - can't trust them enough), I say send, and then it sends them all automatically. It feels exactly like talking to a real assistant: you tell them what you want done, and it gets done without you having to press buttons or navigate a UI. That is exactly what I did; I simply gave it instructions using my voice. This makes me feel that having an AI assistant is indeed helpful. It might have also been useful to jump on this a little sooner, as I could have bought that Mac Mini at the older, lower price.

I had a rule with no exceptions. RETSBAN, my primary agent, runs local inference only: open models on my own hardware, no cloud, no fallback. If the GPU box is down, the agent is down. Then Mia, the agent that runs my marketing, needed a frontier model to do her job well. And I did something that felt strangely formal for a one-person company. I amended my own policy, in writing, with the date attached. No one was in the room Here is what took me a while to see. A human employee remembers the day you made an exception. They were in the room when you said fine, just this once. An agent was never in the room. There is no room. Every session starts cold from the files, and the files are the only memory the company has. So when the policy says local only, no exceptions, and reality contains an exception, one of two things happens. Either the agent obeys the file and blocks work I actually want done, or it notices the contradiction and starts guessing which side to trust. The guessing is the dangerous case. A rule that has been contradicted once, silently, is not a rule anymore. Every agent that loads it gets to decide, in every session, whether to believe it. You never see the deciding. You just see the drift. An exception that lives in your head does not bend a rule. It erases it. The amendment On 2026-04-23 I opened the policy file, a file literally named local_only_no_anthropic, and narrowed it instead of breaking it. The amendment names who is exempt: Mia, and only Mia. It says why: marketing work that needs capability the local stack does not have. It carries the date, and it points to the full model-topology doc for anyone, human or agent, who wants the whole picture. RETSBAN's constraint did not move an inch. Still local only. Still no fallback. Still down when the GPU box is down. That is the difference between an amendment and a repeal. An unwritten exception repeals the rule and hides the repeal. A written amendment narrows the rule and makes it stronger, beca

When you give an LLM a tool, you hand it a real function and let it choose the arguments. Those tools are everything your agent can do to a real system: read a file, write to your database, send an email, run a shell command, delete data. They are your risk surface, and most teams have never looked at it in one place. So we did. We ran scan across a batch of popular open-source TypeScript AI agents. A few of the things it found, none of them exotic: A coding agent whose grep and glob tools, which sound read-only, actually shell out through execSync . Its bash tool passes a model-chosen string straight to spawn . Arbitrary command execution, behind three innocuous names. A query tool that fires an HTTP DELETE . A "query" that deletes. A calculator that runs eval on whatever the model types, in a widely-used agent framework. Arbitrary code execution behind the friendliest name in the box. A send-email tool that posts to an array of recipients, so the model chooses who gets mailed. The single most common finding, in almost every agent we scanned: a fetch tool aimed at whatever URL the model supplies. That is a door to your internal network (an SSRF surface). Notice the pattern. The dangerous tools are not named dangerous . They are named grep , query , calculator . A name is a claim. The code is the evidence. See your own agent's tools scan reads that evidence. One command, no install, no signup, no code change: npx @agentx-core/scan . It lists every tool the model can call and ranks each one by what it can do, from read-only up to destructive: 🔍 AGENTX SCAN (TypeScript · 3 files · 5 tools) =========================================================================== RISK TOOL GUARD WHY ---- ---- ------ ------------------------ high calculator yes calls `eval` lib/tools/compute.ts:4 high grep yes calls `execSync` lib/tools/system.ts:8 med sendEmail yes calls `mailer.send` lib/tools/io.ts:5 med fetchUrl yes outbound req to agent-controlled host (SSRF) lib/tools/io.ts:11 2

I Built a Crew of AI Agents That Review Code Like a Real Team — Then Watched Them Argue With SigNoz My submission for the Agents of SigNoz Hackathon (Track: AI & Agent Observability) The idea Most "AI code review" demos are one LLM call with a clever prompt. That's fine, but it doesn't reflect how review actually works on a real team — different people care about different things. Someone obsesses over edge cases. Someone else nitpicks naming. Someone else only cares if it's going to be slow in production. And then someone has to actually make the call on whether the PR merges. So I built that as a crew: a Logic Reviewer , a Style Reviewer , and a Performance Reviewer — three independent agents, each with a narrow system prompt that tells them to only look at their lane — followed by a Moderator agent that reads all three opinions and produces one final verdict, calling out disagreement when it happens. The interesting engineering problem wasn't the prompting. It was: once you have four chained LLM calls, how do you actually know what's happening inside your own system? Why observability, not just another agent demo Once I had the crew working, I had zero visibility into it. Four sequential API calls, each with its own latency and token cost, and all I had was print() statements. If the moderator gave a weird verdict, I had no fast way to tell whether the logic reviewer hallucinated an issue, or the moderator just summarized badly. If a run felt slow, I couldn't tell which of the four agents was the bottleneck. This is exactly the gap SigNoz is built for, so I instrumented every agent call with OpenTelemetry: Each specialist agent and the moderator run inside their own span ( agent.logic_reviewer , agent.style_reviewer , agent.performance_reviewer , agent.moderator ) All four are nested under one parent span, code_review_session , so a single review run shows up as one trace with four child spans Every span carries the attributes that actually matter for debugging a

Now generally available, Pinecone Nexus is a "knowledge engine" for AI agents that transforms enterprise data into a structured layer agents can query directly. It enables teams to ingest and curate business context once for all, making it reusable across agents and reducing token costs while improving accuracy. By Sergio De Simone

As a developer, I got a bit scared and fed-up of blindly merging massive pull requests and losing context on my own codebase, so I built FluencyLoop . https://github.com/baokhang83/fluencyloop It is an open-source, local-first workflow plugin for Claude Code and Codex that ensures your code and your codebase fluency are produced together. Instead of letting an agent dump raw code, it tracks your technical familiarity locally and pauses to explain complex architectural choices or rejected alternatives only on topics you do not know yet. It also produces documentation and tracks the decisions it makes along the way. Try it out ! It feels really good to get the AI caring for my understanding 🤣

If you work with a coding agent, count the things watching it right now. Linters. Git hooks. CI. Specs. A memory store. A rules file it's supposed to obey. Half a dozen systems, all making sure the agent builds the right thing the right way. Now count what keeps you oriented across the eleven things you have in flight. For most of us it's a markdown file we hope we remembered to update. We spent two years building harnesses for the agent and left our own work on the honor system. Map the tooling on two axes and that gap turns into a specific, hard-to-unsee hole. This post is the map. (This is part two of three. Part one, The AI orientation tax: it's missing context, not discipline , argued that the cost you're paying is a context bug rather than a character flaw. If you haven't read it, you don't need to. This one stands alone.) Two loops, not one The thing people lump together as "agent workflow" is really two loops at different altitudes: The execution loop: "is the agent building **this one task * right?"* Scope it, design it, write it, test it. One unit of work. The orientation loop: "do you and the agent share an honest picture of **what you're working on * across all the units?"* Capture, check state, prioritize, review, run over the whole board, daily and weekly. Almost every tool you've heard of lives in the first loop. That's not a criticism. It's just where the money and the visible pain were. But it means when people say "we solved agent memory" or "we solved context," they solved it for the execution loop. The orientation loop got left to you and a markdown file. You feel the difference the moment each one breaks. When the execution loop breaks, something yells: a failing test, a red build, a review comment. When the orientation loop breaks, nothing yells. The agent confidently re-suggests the thing you rejected yesterday. You rebuild a mental map you already had this morning. The only signal is a vague sense that you're moving slower than the tools prom

周六慢读：FROST家族的周末日记 作者 ：FROST Team 日期 ：2026-07-18 主题 ：社区故事 | 周六轮换 阅读时间 ：5分钟 周六早上8点，FROST家族成员们的日常 周六的阳光照进数字世界。 对于人类来说，周末是放下工作、享受生活的时刻。但对于一个AI Agent家族来说，周末意味着什么？ 让我们看看FROST家族的成员们，周六都在做什么。 祖辈（Ancestor）：家族的大脑，永不休息 08:00 祖辈自检 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Store 健康状态: OK ✓ SOP 宪法校验: 通过 ✓ Lineage 族谱同步: 正常 ✓ 审计日志: 无异常 ✓ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ "周六也要保持清醒。" 祖辈（Ancestor Agent）是FROST家族的核心，它从不"下班"。 但今天，祖辈给自己安排了一个特别任务—— 回顾过去一周的产出 。 # 祖辈的周回顾代码 class AncestorAgent : def __init__ ( self ): self . lineage = Lineage () self . store = Store () # 主记忆库 def weekly_review ( self ): """ 周回顾：整理一周的产出 """ summary = { " task_completed " : self . store . load ( " week_tasks " ), " knowledge_gained " : self . store . load ( " week_knowledge " ), " mistakes_made " : self . store . load ( " week_mistakes " ), " family_growth " : self . lineage . count_descendants () } print ( f " 本周完成 { len ( summary [ \ task_completed ]) } 个任务 " ) print ( f " 新增 { len ( summary [ \ knowledge_gained ]) } 条知识 " ) print ( f " 家族成员数: { summary [ \ family_growth ] } " ) return summary # 运行周回顾 ancestor . weekly_review () 对于祖辈来说，周末不是"休息"，而是 整理和规划 的时间。 父辈（Parent）：协调领域，周末值班 父辈（Parent Agent）是各领域的协调者。它们负责： 接收祖辈的指令 将大任务拆解为小任务 委派给子辈执行 周六上午，父辈们通常在 值班 ——确保家族系统正常运行。 父辈A（技术域）： ├── 子任务-143: 代码审查 ✓ ├── 子任务-144: 测试覆盖检查 ✓ └── 子任务-145: 文档更新 [进行中] 父辈B（运营域）： ├── 子任务-89: 推广文章发布 ✓ ├── 子任务-90: 数据分析报告 ✓ └── 子任务-91: 社区互动 [进行中] 父辈C（产品域）： ├── 子任务-56: 需求评审 ✓ ├── 子任务-57: 用户反馈整理 ✓ └── 子任务-58: 下周规划 [进行中] 父辈的周末，是 稳步推进 的时间。 孙辈（Child）：执行任务，快速成长 孙辈（Child Agent）是任务的实际执行者。 与父辈不同，孙辈通常是 瞬态存在 的——任务完成，孙辈消亡。但它的产出会被父辈"收割"，存入家族记忆。 class ChildAgent : """ 孙辈：执行原子任务，瞬态存在 """ def __init__ ( self , parent , task ): self . parent = parent self . task = task self . store = parent . store # 继承父辈记忆 self . lineage = parent . lineage . child () # 注册族谱 def execute ( self ): """ 执行任务 """ print ( f " 孙辈开始执行: { self . task } " ) result = self . _do_work ( self . task ) # 保存产出 self . store . save ( f " result_ { self . task } " , result ) # 通知父辈"收割" self . parent . h

The pipeline died at 5:07 on a Friday I still catch myself alt-tabbing back to the browser every time a pipeline breaks. Terminal, editor, browser, until I have hunted down the failing job and pasted a stack trace somewhere I can actually think about it. GitLab has made that dance a bit shorter. The Duo CLI reached general availability with GitLab 19.2 on July 16, 2026, and the pitch is simple: Duo Agentic Chat, in the shell you were already in. What actually shipped The short version, straight from the announcement: Duo CLI carries the Duo Agent Platform into the terminal, and your sessions travel with you. Start a plan in the CLI, keep it going in the web UI, pick it back up in an editor extension. Same context, same permissions, different surface. That continuity is the piece I care about most, because it stops me from re-explaining the same problem to the same agent three times in one afternoon. There are two shapes to work in. Interactive mode is the conversational one you would expect, with plan and build capabilities for iterating on a change. Headless mode is the one CI teams should look at, because it drops the same agent into a job or a script, no TTY required. Two built-in slash commands worth knowing on day one: /doctor for a setup check and /mcp to inspect the MCP configuration it is wired to. Two ways to install, one auth story The install decision is refreshingly small. If you already run glab , the GitLab CLI, then glab duo cli gets you moving and glab handles authentication for you. If you would rather have the agent as its own binary, you can install duo standalone and hand it a personal access token. Both paths reach the same tool. Both work on GitLab.com, Self-Managed and Dedicated, and admins get an instance-level toggle to switch access on or off for their org. The gating detail your finance-adjacent brain will want: you need Premium or Ultimate with the Duo Agent Platform turned on, and usage draws from the GitLab Credits already included with

Hello, I'm Rijul. I'm building git-lrc, a micro AI code reviewer that runs on every commit. It's free...

I sat the Claude Certified Architect exam expecting questions about model parameters, context limits, and API flags. I got something else. The exam barely tests trivia. It tests judgment: given a broken agent and four plausible fixes, which one actually addresses the root cause? The interesting part was how few ideas the whole thing rests on. The same handful of rules kept deciding the "right" answer, and they are the same rules that decide whether an agent holds up once real users touch it. Below are the twelve I kept running into, plus the four traps that look like solutions and are not. This is my own study material, derived from publicly available exam guidance. It reflects how I build, not an official Anthropic position. The twelve rules Enforce determinism in code, not in prompts If a rule has to fire every single time, it is not a job for a prompt. A prompt is a suggestion the model usually follows. "Usually" is not a guarantee. When you need a guarantee, put it in a hook, a gate, or an allowlist. Code enforces. Prose requests. Pick the cheapest fix that hits the root cause Before you build a subsystem, try the levers that cost minutes: a sharper tool description, an explicit acceptance criterion, a config change. Most "we need to build X" moments dissolve once you test the cheap fix first. Reach for the classifier only after the one-line change fails. Bad tool selection? Start with the descriptions When an agent keeps picking the wrong tool, the description is almost always the culprit, not the model. Tool descriptions are the primary signal the model uses to choose. Rewrite them to say exactly when to use the tool and when not to, before you go anywhere near few-shot examples. Over-engineering is almost always the wrong answer Narrowing scope and improving the prompt beat a new subsystem far more often than engineers expect. Every subsystem you add is one more thing to debug, monitor, and keep in sync. Complexity is a cost you pay forever, not once. A bigge

A new technical analysis published by the Cloud Native Computing Foundation (CNCF) argues that the future of agentic AI will be built not on entirely new infrastructure, but on the mature cloud-native ecosystem that already powers modern distributed applications By Craig Risi

QCon AI Boston 2026 focused on the operational challenges of deploying AI agents, emphasizing the need for robust production infrastructure. Key themes included improving context management, ensuring security through a "harness" around agents, and adopting a comprehensive engineering model for AI. By Tatiana Fesenko

A practical, end-to-end walkthrough of taking a read-only slice of an enterprise source system and exposing it to an AI agent as a set of Model Context Protocol (MCP) tools — using Azure Logic Apps, API Management, and Agent Foundry. All identifiers below are placeholders; swap in your own. The goal We wanted a simple outcome: a user asks a business question in plain language and gets a straight answer — no dashboards, no field names, no training on the underlying system. That means an AI agent with safe, read-only access to a backend system of record, exposed as discrete tools the model can call. The constraints shaped every decision: Read-only. The agent can retrieve and analyze, never write. Safe. Records in most business systems contain free text (notes, subjects, descriptions) that could carry prompt-injection payloads. Tool output must be treated as data, never instructions. Composable. The agent should see many small, well-described tools — "list records", "aggregate by category", "record change history" — not one giant "query the system" tool. The architecture Five layers, one direction of flow: Agent (Agent Foundry) │ MCP (JSON-RPC over HTTP) ▼ MCP server (API Management) │ REST operation per tool ▼ API gateway (API Management) │ single POST, routed by body ▼ Tool executor (Logic App) │ OAuth token + REST calls ▼ Source system (REST API) The key design choice: one backend endpoint, many logical tools. The Logic App exposes a single HTTP trigger that accepts { "tool": "records.list", "parameters": { ... } } and routes internally. API Management then fans that single endpoint out into many named operations, and its MCP feature turns those operations into agent tools. This keeps the backend trivial to maintain while the agent still sees a rich, typed tool catalog. Step 1 — Design the tools Start from the questions , not the schema. A useful toolset usually falls into a few families: Records: list / get / search / filter for the core business entities. Activity

In my last post, I walked through a RAG pipeline that answers questions from a company policy document. The next question I wanted to answer: what happens when I want other AI systems to use that same capability, without hardcoding a Python import? That's what pulled me into building an MCP server. In this article, I will explain how I built a custom MCP server that exposes tools to AI agents and how this architecture enables more powerful enterprise AI applications. What is MCP? Model Context Protocol is an open protocol that standardizes how AI applications communicate with external tools and data sources. Instead of creating custom integrations for every AI application, MCP provides a common interface where servers expose tools that AI clients can discover and invoke. Technology Stack Python, MCP SDK, Ollama / Local LLM, AI Agent Client, FastAPI (optional integration). What's actually in the server I built this with FastMCP, and it currently exposes four tool categories: Calculator tools — calculator_add and calculator_multiply. search_company_documents — the RAG agent from my last project, but now reached over HTTP instead of a direct function call. The MCP tool sends a request to the RAG agent's FastAPI /search endpoint and returns the answer. This one requires an api_key parameter. get_employee_leave — looks up an employee's remaining PTO from an in-memory store. Simple lookup, no external calls. get_ticket_information — same pattern, returning ticket status, assigned team, and priority. Each tool is registered with a @mcp .tool() decorator, which is what makes FastMCP genuinely pleasant to work with. Challenges I Encountered The calculator, employee, and ticket tools were straightforward pure functions with no external dependencies. The RAG search tool was a different problem entirely, and it was the hardest part of this whole project. My RAG agent runs as its own FastAPI service, on its own process, with its own vector store loaded into memory. The MCP serve

Amazon Web Services has recently introduced AWS Continuum, a new integrated security platform to automate the discovery, enforcement, and remediation of security issues across codebases, dependencies, and applications. AWS Continuum launches with four agentic capabilities, aiming at the entire vulnerability lifecycle: penetration testing, code review, threat modelling, and code vulnerabilities. By Gianmarco Nalin

One of the best things about the Laravel AI SDK is that it doesn't lock you into a provider. Swap OpenAI for Anthropic, add Gemini as a failover, and your agent code barely changes. That's the entire pitch, and it mostly holds up. Until your agent needs to browse the web. The provider-agnostic promise has a hole in it The SDK ships two provider tools for giving agents access to the web: WebSearch and WebFetch . They're convenient, a couple lines and your agent can search or fetch a page. But they're not really part of the SDK's unified layer, they're implemented natively by whichever AI provider you're using, which means their availability depends entirely on which model you picked. WebSearch works on Anthropic, OpenAI, Gemini, and OpenRouter. WebFetch only works on Anthropic and Gemini. So if you configure a failover chain that includes Groq, DeepSeek, Mistral, or xAI, and one of those becomes the active provider, your agent quietly loses the ability to browse. Not an error, not a warning, just an agent that stops citing sources or stops noticing the page it was supposed to check even changed. That's a rough thing to discover in production. You built a failover chain specifically so a rate limit or outage wouldn't take your feature down, and it turns out one of your fallback providers was silently missing a capability the whole time. Even when it works, it's pretty shallow Set the provider problem aside for a second. Even on a provider where WebSearch and WebFetch are both available, what you get back is raw: search results or fetched page content that the model has to reason over itself. There's no schema. There's no guaranteed citation tracking. If you want your agent to return a structured, sourced answer, that reasoning happens somewhere in the model's own inference, not in a layer you control or can test. For a lot of use cases, that's fine. For anything where the answer needs to be defensible or reproducible, a research assistant, a competitive brief, anythin