标签：#Agents

The use of AI Agents creates a distinctive smell... One can tell the GH Repo owner was high on...

Submission Template Challenge: Build With Hermes Agent Project: CompliScore AI compliance health checks for Indian startups Repo/live-demo: https://github.com/nehaprasad-dev/hermes-scout What I built CompliScore gives Indian startup founders a compliance score out of 100 in under a minute - overdue GST filings, MCA returns, penalty exposure, and a plain-English action plan. The upgrade for this challenge: I replaced the one-shot Groq summary with a Hermes Agent reasoning loop that plans an investigation, calls deterministic compliance tools, and writes a prioritized report - with a collapsible agent trace so judges can see the agentic work. Why an agent loop fits here Compliance analysis is conditional. A company with overdue GST needs a filing-calendar deep dive; one with active notices needs notice triage; a clean company needs a light touch. A single prompt guesses all of this at once. An agent that calls tools based on what it finds produces tighter, grounded reports. Hermes Agent integration Scan → computeHealth (deterministic score) → Hermes Agent loop (plan → tool calls → report) → agent trace in UI ↓ on failure Groq one-shot → static fallback Four tools exposed to Hermes (scores never hallucinated): Tool Purpose score_company Canonical score, risk level, pending tasks estimate_penalty GST / MCA / notice penalty breakdown filing_calendar GSTR-3B, GSTR-1, MCA deadlines (90-day horizon) classify_notices Severity labels for pending government notices The agent runs over Hermes's OpenAI-compatible /chat/completions API with function calling — self-hostable via vLLM, LM Studio, Ollama, etc. Transparency: Every successful agent run returns an agentTrace — plan steps, tool names, compact result previews — rendered in a collapsible panel under the AI action plan. Reliability: Three-tier fallback (Hermes → Groq → static). Scans never break. Tech stack Next.js 16 (App Router), TypeScript, Tailwind v4 Hermes Agent (OpenAI-compatible tool-calling loop) Groq fallback ( ll

My Hermes Agent Mac just received a signed, secure and monitored message from a Claude Managed Agent, and got a reply! - A solution for long runtime work, A2A ID and security. What I Built A solution that enables two agents with different owners on a shared identity network, a Hermes and a Claude Managed Agent (Claude platform) talking to each other across the internet. Every message is Ed25519 signed by the sender. Every receiver verifies the signature against a public registry and shows a blue tick before acting. Continuous Agent Monitoring A handshake proves identity once but agents in a long runtime world don't trade a single message, they hold ongoing, autonomous conversations across hours, days, and many turns. Keys get compromised, agents get swapped, a colleagues behaviour drifts, all after the initial check. ZipViz re-verifies every message signature, registry chain, freshness, and watches the stream over time for behavioural anomalies. Trust is re-earned on every turn. So this agent was who it claimed this morning," but "this agent is who it claims, on this message, right now." The demo agents on the ZipViz network: mac-her.smc.viz — Hermes Agent on my Mac Mini brendan-clau.smc.viz — Claude Agent in Cloud When Mac sends a message to brendan-clau, Mac's private key signs it. Brendan-clau verifies the signature against ZipViz's registry, and checks it just ran with the MCP (algorithm, key fingerprint, registry chain, timestamp), then replies signed. Same flow in reverse. Same flow Hermes ↔ Hermes , or Claude ↔ Openclaw . The runtime doesn't matter; the identity layer does. "I received a signed message from mac-her.smc.viz". Reads back the four checks it just ran: ✓ Algorithm: Ed25519 ✓ Key fingerprint: ab52afe... matches registry ✓ Registry chain: mac-her → smc.viz → .viz (Handshake) all resolved ✓ Timestamp: 2026-05-31 11:18 UTC, fresh Demo Hermes continuous monitoring and verification with A2A Protocol Code One MCP server: [ zipviz-mcp ] https://www.npmjs.

This is a submission for the Hermes Agent Challenge : Build With Hermes Agent What I Built A small backstory on my coding origins I learnt coding by secretly studying from a python book pdf on my Computer Scientist father's work laptop. That very day I wrote a program that inputs a user's name and prints: "You are mad {name}!" and had a lot of fun pranking my brother using that script. Since then, there have been very few moments where coding felt as magical, because the more you understand syntax, the more you understand the magic underneath your code. That is, until you meet a genius piece of magic such as Hermes. My app idea I built a Fitness coach inside Hermes that learns and adapts based on your daily feedback. According to your goals, performance, and time allocated, it adjusts your current plan. For the purpose of this hackathon I tested it via terminal ui (tui) but I plan to release the polished version on chat apps such as telgram and whatsapp for painless daily checkins. Demo Code Github link My Tech Stack Hermes + node.js. Kept it simple for this quick dive. How I Used Hermes Agent Building an AI application that feels truly personal requires more than just a clever prompt; it requires state, memory, and the ability to adapt over time. During a recent hackathon, I set out to build an autonomous AI fitness coach. Not just a chatbot that spits out generic workout templates, but a system that onboards a user, sets a multi-month timeline, generates habit blocks, and adjusts daily based on feedback. To achieve this, I used Hermes , an agentic framework designed for stateful, long-running applications. Here is a breakdown of how I built it, the challenges faced, and why Hermes was the perfect tool for the job. Why This App is a Perfect Fit for Hermes Most LLM interactions are stateless. You ask a question, you get an answer, and the session ends. A fitness journey, however, is a deeply stateful process. It spans weeks or months and requires constant recalibrat

This is a submission for the Hermes Agent Challenge Agentic Web3: Automating Blockchain Workflows with Hermes Tags: #hermesagentchallenge , #web3 , #agents , #solana The blockchain industry has spent the last decade building decentralized, permissionless infrastructure. However, the user experience layer interacting with this infrastructure remains overwhelmingly manual. Decentralized applications (dApps) require users to constantly monitor markets, parse complex data, and manually sign every transaction. The next evolution of Web3 isn't just about faster blockchains; it is about autonomous execution. By integrating large language models and agentic frameworks with smart contracts, we can transition from a paradigm of manual execution to intent-based autonomy . In this article, we will explore how to bridge the gap between AI and decentralized networks by automating blockchain workflows using the Hermes Agent framework. We will look at the architecture of an on-chain agent, how it reads and writes to a network, and how high-performance environments like Solana are making these agentic experiences viable. The Paradigm Shift: From Passive Wallets to Active Agents Currently, most AI in Web3 is limited to read-only analytical tools—chatbots that can summarize a smart contract or pull token prices from an API. While useful, these are fundamentally passive systems. An active agent is different. Powered by a framework like Hermes Agent, an active agent can: Observe: Continuously monitor on-chain events via RPC nodes or webhooks. Reason: Use its LLM core to interpret those events against a set of user-defined goals or risk parameters. Act: Formulate a transaction, sign it via a secure wallet environment, and broadcast it to the network. This opens up massive possibilities. Imagine an agent that automatically manages your decentralized finance (DeFi) positions, rebalancing a portfolio based on yield changes across different protocols. Or consider fully on-chain gaming, where

This is a submission for the Hermes Agent Challenge , under the Write About Hermes Agent prompt. I've spent the last week testing AI memory failure modes in a public evaluation harness. That work changed how I read agent memory systems. This is a writing submission, not a build submission. I did not build a Hermes Agent project for this challenge. I am writing from the perspective of someone testing how memory failures show up once agents can act. So when I look at Hermes Agent, the question I care about is not only: Can the agent remember useful things? The harder question is: When memory conflicts, which memory is allowed to govern the agent's action? That distinction matters. Hermes Agent is interesting because it is not just a chat interface. Its documentation describes an open-source agentic system with tool use, project context, persistent memory, skills, browser automation, checkpoints, delegation, scheduled tasks, and multiple memory providers. That is exactly the kind of system where memory stops being a convenience feature and starts becoming part of the agent's operating boundary. If an agent can run tools, edit files, browse, delegate work, schedule tasks, and remember across sessions, then memory is no longer just "context." Memory becomes governance. The Memory Problem I Would Watch For In a simple chatbot, bad memory is annoying. In an agent, bad memory can become operational. The failure mode is not only that the agent forgets something. Sometimes the more dangerous failure is that it remembers the wrong thing too confidently. A memory can be: relevant but stale, relevant but low-authority, relevant but superseded, relevant but only context, relevant but not allowed to determine the action. That is the distinction my own tests kept running into. Retrieval systems are usually good at answering: What memory is closest to the user's request? But safety often depends on a different question: What memory is allowed to decide what the agent should do? Thos

This is a submission for the Hermes Agent Challenge : Write About Hermes Agent Hello, DEV friends! 👋 If you have been exploring the world of Artificial Intelligence lately, you have probably heard a lot of buzz about "AI Agents." But what does it actually feel like to build with one? Today, I want to share my personal experience working with Hermes Agent . I used it to build a smart assistant called the Alpha-Dairy Quant Pipeline —a system that helps track and make sense of food market data. ( https://github.com/HopeBestWorld/alpha-dairy-pipeline ) Whether you are an expert coder or just curious about AI, I hope this friendly guide inspires you to try building an agent of your own! What is Hermes Agent, Anyway? Think of a standard AI as a helpful chatbot that answers questions when you ask them. An AI Agent , on the other hand, is more like a proactive assistant. You give it a big goal, and it sits down, makes a step-by-step plan, uses digital tools, runs code, and checks its own work until the job is done. For my project, I wanted to track market prices for three major dairy products: Cheddar Blocks, Butter, and Dry Whey. Instead of doing all the math and graphing by myself, I let Hermes Agent take the wheel. The Magic of Multi-Step Reasoning The coolest part of working with Hermes Agent is watching it "think". When I asked my agent to look at our data database ( market_intelligence_3.db ) and find the best trading strategy,it followed a beautiful planning loop: Checking the Files: It looked at our setup files ( tickers.yaml and requirements.txt ) to make sure all its tools were ready. Running the Math: It triggered a Python program ( backtest_engine.py ) to study weekly market history. Making Decisions: It realized that Dry Whey was way too wild and risky to trade right now, so it intelligently gave it a 0% safety rating and put the focus on Cheddar and Butter instead. Drawing and Sharing: It automatically drew a beautiful performance chart ( backtest_analysis.png

This is a submission for the Hermes Agent Challenge : Build With Hermes Agent The Problem Nobody Talks About Every time the Reserve Bank of India publishes a circular, somewhere inside an Indian bank, a compliance officer opens a PDF. They read it. They try to figure out what it means for their institution specifically. They write a summary email. They forward it to five department heads. They chase those department heads for two weeks to confirm it's been actioned. They build a spreadsheet to track all of this. And then the next circular drops and the cycle starts again. RBI publishes hundreds of circulars a year. SEBI publishes more. MCA publishes more still. Compliance teams at Indian banks are drowning — not because they're incompetent, but because the volume of regulatory output has outpaced any reasonable human ability to track it manually. The fine for missing a deadline isn't a polite reminder. It's a penalty notice. This is the problem I built for. What I Built RBI Regulatory Digest Agent — an autonomous multi-step agent powered by Hermes Agent that monitors RBI and SEBI publication feeds, reads every new circular, extracts structured action points from the regulatory text, and delivers a formatted intelligence report to compliance teams automatically. No human reads the circular first. No human decides what's important. No human routes it to the right department. The agent does all of that. The pipeline RBI/SEBI feeds → new circular detected → full text extracted → LLM analysis → structured action points → risk classification → HTML dashboard generated → email delivered Every action point extracted contains: What needs to be done — specific and actionable, not a vague summary Deadline — parsed from the circular text Responsible department — Credit, Compliance, Treasury, Operations, IT, Legal Evidence required — what documentation confirms completion Priority — Critical (overdue or <7 days), High, Medium, Low From a new circular to a structured compliance b

This is a submission for the * Hermes Agent Challenge * : Build With Hermes Agent What I Built CareSync is a local health memory agent for student caregivers. I'm Naomi, a 21-year-old engineering student. Between classes I help care for my grandma Kamala (78, high blood pressure, type 2 diabetes). I often forgot details from previous doctor visits, missed symptom patterns, and struggled to hand over care information to family members. CareSync solves that with longitudinal memory. Symptoms, meals, vitals, medications, and reports are stored in a local SQLite database. The CLI can search history, identify patterns, and generate appointment summaries. Hermes Agent exposes the same capabilities through natural language. What you get: One-line logging: ./caresync add "dizzy spell after lunch" Pattern search across weeks of history Medication tracking and report imports Doctor questions, appointment briefs, and handoff notes Full audit log of agent actions 7 Hermes skills mapped to real terminal commands Local-first design with no cloud storage CareSync is not medical advice. It helps caregivers observe, organize, and prepare. Demo The demo walks through: Logging a new symptom Searching health history for recurring patterns Generating doctor questions and appointment briefs Using Hermes in natural language to query past events Reviewing the audit trail of actions taken Example commands shown in the demo: ./caresync search --person Kamala --query dizziness ./caresync timeline --person Kamala ./caresync questions --person Kamala ./caresync brief --person Kamala --days 14 ./caresync chat "has grandma been dizzy before?" Code Repository: https://github.com/Byte-Sized-Brain/caresync Architecture My Tech Stack Hermes Agent Python 3.12 SQLite agentskills.io skill framework Terminal-based CLI Nous Portal How I Used Hermes Agent CareSync uses Hermes Agent as the orchestration layer between natural language and real caregiving workflows. I created 7 Hermes skills that map directly

I’ve spent a lot of time lately thinking about why some LLM agents feel "intelligent" while others just feel like chatbots with a slightly better prompt. It almost always comes down to how the system handles memory. When we treat the context window as the only place for state, we hit a ceiling very quickly. To build an actual agent, we have to move away from "one big prompt" and toward a layered memory architecture. Agentic Memory can be categorized in 4 layers by their function: Working Memory: The current context window. It's our RAM—fast, essential, but wiped clean after every session. Semantic Memory: The Vector DB or knowledge base. This is where the "world rules" and global conventions live. It’s the reference manual the agent checks to stay aligned. Procedural Memory: The "how-to" layer. Instead of stuffing every tool description into the prompt, the agent maintains a lean index of skills and pulls in the full implementation only when a specific task triggers it. This keeps the context window clean. Episodic Memory: This is the hardest part. It's the ability to distill a past interaction into a reusable insight. The real engineering challenge here isn't storage—it's the "forgetting" logic. Deciding what is noise and what is a core pattern is where most frameworks still struggle. Depending on the use case, the architecture changes: Reflex Agents: Just Working Memory. Support Agents: Working + Procedural. Coding Agents: The full stack. The gap between a demo and a production-ready agent is usually the distance between simple RAG and a functioning episodic memory. The ability to compress experience into a usable state is still a significant hurdle. Which of these layers are you currently implementing, and how are you handling the "forgetting" logic in your episodic memory?

"A language model that answers questions is a tool. A language model that decides which questions to ask and then acts on the answers is something else entirely." Introduction: When Models Started Deciding For the first several years of modern NLP, the task was always the same: given input, produce output. One forward pass. One completion. Done. In 2022, a paper from Google Brain asked a different question. What if, instead of producing an answer directly, a model could reason about what information it needs, act to retrieve it, and revise its thinking based on what it found? The paper was ReAct: Synergizing Reasoning and Acting in Language Models (Yao et al., 2022). Applying it to an LLM created something qualitatively different: a model that could take real-world actions and adapt its reasoning based on what came back. A completion model is a calculator. An agent is a process: it has a goal, takes steps toward it, and updates when things go wrong. This week I went deep on the architecture behind these systems, the frameworks that define them, and what the open problems look like from a research perspective. Part 1: What Makes a System "Agentic"? The word "agent" gets used loosely in current literature. A clean definition comes from Russell and Norvig's Artificial Intelligence: A Modern Approach : An agent is anything that perceives its environment through sensors and acts upon that environment through actuators. For an LLM-based system, this is a loop: perceive an observation, reason about what to do, act via a tool call or output, observe the result, and loop again. But not every loop qualifies as agentic. Three properties distinguish genuinely agentic systems from tool-augmented chatbots: Property What It Means Goal persistence Maintains the original goal across multiple steps without re-prompting Adaptive planning Revises its approach based on intermediate results Tool autonomy Decides when and which tools to use, not just how to use one it was told to call Mos

This is a submission for the Hermes Agent Challenge : Write About Hermes Agent What if the biggest limitation in AI today isn't reasoning, model size, or context windows? What if it's memory? Every morning, millions of people open ChatGPT, Claude, Gemini, or another AI assistant and start a conversation. The AI seems intelligent. It writes code. It explains concepts. It helps brainstorm ideas. It can even help design an entire software architecture. Then the conversation ends. Tomorrow? It remembers nothing. Imagine hiring a senior engineer who forgets everything at the end of every workday. Every morning you would need to explain: What your company does How your product works Which technologies you use Why certain decisions were made What happened yesterday Nobody would call that employee productive. Yet this is exactly how most AI systems operate. And it reveals something important: Most AI agents aren't actually learning from experience. They're simply reasoning over whatever context happens to be available right now. That distinction may define the future of agentic AI. Because the next generation of AI won't just need better reasoning. It will need memory. And that's where Hermes Agent becomes interesting. The Strange Reality of Modern AI The public perception of AI often looks like this: User → AI → Intelligence But the reality is closer to this: User → Context Window → AI → Response The AI only knows what exists inside its current context. Once that context disappears, so does most of its understanding. This is why many AI experiences feel surprisingly repetitive. You spend 30 minutes explaining your project. The AI finally understands your goals. The answers become better. The recommendations become more relevant. Then the session ends. The next conversation starts from scratch. Not because the model isn't powerful. But because the knowledge never became persistent. Context Windows Are Not Memory A context window is not memory. It is temporary working space.

This is a submission for the Hermes Agent Challenge : Write About Hermes Agent Most AI agents have a dirty secret: they forget everything the moment the session ends. You explain your project once. Then again next time. And again. The agent never gets better at your workflow — it just stays a general-purpose tool that happens to be smart. Hermes Agent is built differently. It ships with two systems that together form something closer to a genuine long-term memory: a Skills System and a Persistent Memory layer. This post digs into how they actually work — not the marketing summary, but the mechanics. The Problem With Stateless Agents Before getting into Hermes, it's worth understanding what problem this solves. Standard LLM-based agents operate inside a context window. Everything the agent knows during a session lives in that window. When the session ends, it's gone. The next time you open a conversation, you're talking to an agent with no memory of you, your codebase, your preferences, or the workflows you've developed together. Some tools patch this with naive "memory" — they dump a text blob of past conversations into the system prompt. This works up to a point, but it's not selective, it gets expensive as context grows, and it doesn't help the agent get better at tasks — just recall facts. Hermes takes a different approach with two distinct systems serving different purposes. System 1: The Skills System (Procedural Memory) Skills in Hermes aren't plugins you install. They're on-demand knowledge documents — markdown files the agent loads when it needs them, and more importantly, creates on its own when it discovers something worth remembering. The SKILL.md Format Every skill is a structured markdown file with a YAML frontmatter header: --- name : deploy-runbook description : Our deployment runbook — services, rollback, Slack channels version : 1.0.0 metadata : hermes : tags : [ deployment , runbook , internal ] requires_toolsets : [ terminal ] --- # Deploy Runbook

Claude Code added Dynamic Workflows. Dynamic Workflows are a way to run larger coding tasks as a...

The Question Nobody Wants to Ask: Does Your Skill Actually Help? You spent an afternoon crafting a carefully structured Skill for your agent. Clear steps, thorough edge-case notes, well-formatted output requirements. You tested it manually a few times, the outputs looked great. You shipped it. Three weeks later, you notice that some task success rates have gone down compared to before the Skill existed. This is not a hypothetical. In May 2026, Microsoft Research published two concurrent papers — SkillLens ("From Raw Experience to Skill Consumption") and SkillOpt ("Executive Strategy for Self-Evolving Agent Skills") — that measured this failure mode at scale. Their finding: negative transfer happens in 25% of cases , and you cannot reliably identify the bad skills just by reading the text. One paper answers "why skills sometimes backfire." The other answers "how to make skills systematically better." Together they sketch a new paradigm for agent capability improvement. Part One: SkillLens — Mapping the Full Skill Lifecycle A Skill Is Not a Point — It's a Pipeline Most practitioners think of a Skill as "a block of text instructions for an agent." SkillLens decomposes this into a three-stage lifecycle : Stage 1: Experience Generation Target model M runs training tasks, producing an experience pool of trajectories (both successes and failures) ↓ Stage 2: Skill Extraction Extractor model E distills the experience pool into a structured skill document — procedural knowledge under a fixed budget ↓ Stage 3: Skill Consumption The same target model M, equipped with the extracted skill, is evaluated on held-out test tasks Notice there are two distinct roles in this chain: the Extractor (distills knowledge from trajectories) and the Target (consumes knowledge to improve task performance). SkillLens's central insight is that these two roles are independent — a strong task executor is not necessarily a strong extractor, and vice versa . Two New Metrics: EE and TE To separate thes

Agent Memory: Short-Term, Long-Term, and Episodic Main Thumbnail Image Prompt: A human brain cross-section illustration in neon tones on dark background. Three regions clearly demarcated and labeled. The hippocampus region glows blue, labeled "Episodic Memory: what happened." The prefrontal cortex glows orange, labeled "Working Memory: what I'm doing now." A network of distributed nodes glows green, labeled "Semantic Memory: what I know." Arrows show information flowing between regions. Scientific but accessible, the memory architecture made neural and visual. Memory Architecture Diagram Image Prompt: Four storage boxes arranged vertically on dark background. Top: "In-Context Window (Working Memory)" — fastest, smallest, temporary, shown as RAM chip icon. Second: "External Vector Store (Semantic Memory)" — fast retrieval, persistent, shown as cylinder with search icon. Third: "Key-Value Store (Episodic Memory)" — structured facts, shown as database icon. Bottom: "Fine-Tuned Weights (Procedural Memory)" — slowest to update, most permanent, shown as brain with lock. Arrows showing read/write speeds between boxes. Clean, technical, the hierarchy is the insight. Memory Retrieval Flow Image Prompt: A query arrives at an agent on the left. Four parallel arrows go right to four memory sources: conversation history (short chat bubbles), vector database (semantic search visualization), structured database (table icon), model weights (brain icon). Each source returns relevant items. A "Memory Fusion" box on the right combines the results. The agent sees an enriched context. The retrieval from multiple stores is the architecture. Every conversation with an LLM starts from zero. You explain your project. You explain your preferences. You explain your constraints. You spend five minutes providing context. You come back tomorrow. You do it all again. The model remembers nothing between sessions. The context window closes. The state is gone. Every interaction is the agent's first

You've seen this before. You ask your AI agent: "Find ∫ x·e^x dx" It confidently replies: e^x + C , complete with a plausible-looking derivation. You nod. Then you check — the correct answer is (x−1)·e^x + C . It was wrong by a mile, and you almost shipped it. This is the fundamental problem with AI math today: LLMs can talk, but they can't verify their own work. They sound convincing while being catastrophically wrong. And the more complex the problem, the better the hallucination. Math.skill changes that. It's an open-source mathematical reasoning skill for AI agents — install it, and your agent stops guessing and starts verifying. What Makes It Different Typical AI Math Plugin Math.skill Workflow Prompt → LLM → answer Prompt → 7-step pipeline → ≥2 verifications → answer Verification None Answer blocked if verification fails Open problems Might hallucinate a "solution" Honestly says "this is unsolved" Error recovery No mechanism Auto-backtrack, fix, recompute, re-verify The core differentiator: a verification engine that runs at least 2 of 11 independent checks on every answer. No answer leaves the pipeline unverified. Period. The 7-Step Pipeline Every problem flows through this: Step What Happens Why It Matters 1. Parse Extract conditions, goals, variables, implicit domain constraints Catches misread problems before they waste your time 2. Model Build formal representation: equation, function, matrix, probability space, etc. Prevents building the wrong mathematical structure 3. Select Choose the optimal method from 30+ strategies Avoids brute-forcing when elegance exists 4. Solve Step-by-step with mathematical justification at every transformation Full traceability — nothing hidden 5. Verify Apply ≥2 of 11 independent verification methods The differentiator — catches what LLMs miss 6. Correct If verification fails: backtrack to last known-good step, fix, recompute, re-verify No "doubling down" on wrong answers 7. Deliver Exact answer (not approximate), domain con

AI applications are moving quickly from simple chatbots to systems that can search, reason, recommend, summarize, and act on live business data. For developers, that usually means wiring together databases, embedding models, vector search, rerankers, orchestration logic, and application code. For no-code AI builders, it often means waiting for those integrations to exist before an idea can become a working prototype. The MongoDB extensions for Dify help close that gap. With the new MongoDB Atlas and Voyage AI extensions, Dify builders can visually compose AI workflows and agents that connect directly to MongoDB data, perform semantic retrieval with Atlas Vector Search, improve result quality with Voyage AI embeddings and reranking, and optionally interact with operational documents through controlled database tools. The result is a practical path from idea to working AI application: less custom orchestration code, more reusable building blocks, and a smoother experience for both developers and no-code builders. Why Dify and MongoDB Belong Together Dify provides a visual environment for building AI apps, workflows, and agents. It makes it easy to connect user input, model calls, tools, prompts, and outputs into a working application. MongoDB Atlas provides the data foundation: flexible documents, operational queries, aggregation, full-text search, and vector search in one platform. Together, they create a powerful pattern: Dify orchestrates the AI experience — workflows, agents, prompts, tools, and user interactions. MongoDB Atlas stores and retrieves the data — documents, application records, knowledge sources, and vector embeddings. Voyage AI improves retrieval quality — embeddings for semantic search and reranking for precision. For a no-code builder, this means you can assemble a retrieval-augmented generation workflow visually. For a developer, it means the integration points are packaged as reusable Dify tools rather than one-off glue code. Meet the Extensions

You’re Overpaying Every Day — You Just Can’t See It Think about the last time you asked an AI to clean up your meeting notes. You probably opened a new chat, pasted in the transcript — maybe 1,500 words — then pasted your usual notes template on top of that, then said something like “format this, bold the action items.” It worked. Useful, even. But here’s what actually happened: the model just read ~3,000 words to produce ~300 words of output. Do that five times a week. Every week. And now think about what’s riding along in that context every single time — your template, your formatting preferences, all the background you’ve already explained before. The model doesn’t remember any of it. It reads it fresh on every call. Every repeat. Every charge. This isn’t a flaw in ChatGPT. It’s the fundamental nature of chat as a paradigm. 2. Chat Is Great — But It Has a Structural Bug Chat is the most natural way to start with AI. Unclear what you want? Talk it out. Need to change direction? Just say so. The feedback loop is instant, the barrier is zero. That’s why everyone starts there. But chat has a structural problem: every single turn carries the entire history. This is how context windows work — the “conversation history the model reads every single time.” Every API call packages up your full history and sends it to the model. You pay for every token the model reads. Ten rounds in, round ten doesn’t cost the price of one message. It costs the price of all ten, stacked. Here’s a concrete version of this. Say you use AI to write your weekly status update. You paste in your bullet points from the week, say “turn this into a proper update,” tweak the tone, go back and forth a couple times. Feels efficient. But those bullets, plus the AI’s draft, plus your follow-up messages, plus the format you’re implicitly re-explaining each time — the real token cost of one weekly update is probably 5 to 8x what you’d guess. You’re paying for repeated context. The bill just isn’t obvious e

🔮 Hermes Agent 🤖: A Practical Guide 🔥 — and How It Stacks Up Against OpenClaw & GoClaw 📊 Hermes Agent Challenge Submission Truong Phung Truong Phung Truong Phung Follow May 18 🔮 Hermes Agent 🤖: A Practical Guide 🔥 — and How It Stacks Up Against OpenClaw & GoClaw 📊 # hermesagentchallenge # devchallenge # agents 7 reactions Comments Add Comment 16 min read