<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:media="http://search.yahoo.com/mrss/"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Towards AI</title>
	<atom:link href="https://towardsai.com/feed" rel="self" type="application/rss+xml" />
	<link>https://towardsai.com</link>
	<description>Making AI accessible to all</description>
	<lastBuildDate>Thu, 23 Jul 2026 10:01:33 +0000</lastBuildDate>
	<language>en-US</language>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=6.9.5</generator>

<image>
	<url>https://towardsai.com/wp-content/uploads/2019/05/cropped-towards-ai-square-circle-png-32x32.png</url>
	<title>Towards AI</title>
	<link>https://towardsai.com</link>
	<width>32</width>
	<height>32</height>
</image> 
	<item>
		<title>Siebel 26.6’s RAG-Powered Search: Why Your Support Reps Stop Solving the Same Ticket Twice</title>
		<link>https://towardsai.com/p/machine-learning/siebel-26-6s-rag-powered-search-why-your-support-reps-stop-solving-the-same-ticket-twice</link>
		
		<dc:creator><![CDATA[Eshita Nandy]]></dc:creator>
		<pubDate>Thu, 23 Jul 2026 11:35:33 +0000</pubDate>
				<category><![CDATA[Latest]]></category>
		<category><![CDATA[Machine Learning]]></category>
		<category><![CDATA[Towards AI - Medium]]></category>
		<guid isPermaLink="false">https://towardsai.com/?p=52540</guid>

					<description><![CDATA[Author(s): Eshita Nandy Originally published on Towards AI. A Siebel developer’s honest walkthrough of Retrieval-Augmented Generation in service request search — what it fixes, how the OpenSearch vector pipeline works, and where the gaps still are. Here’s a scenario every Siebel-supported help desk has lived through. A customer types: “the app freezes right after I log in.” Three months earlier, a different customer typed: “system hangs before the dashboard loads.” Same root cause. Same fix, probably. And under the keyword search that most of us have relied on for two decades, these two service requests never meet each other. One rep solves the problem, writes it up, closes the ticket — and the next rep starts from zero, because the search box only understands the words you typed, not what you meant. Cover Image made from CanvaAfter introducing the problem of reps repeatedly rediscovering the same issues due to literal keyword matching, the article explains how Siebel 26.6’s RAG-powered search changes the retrieval model by summarizing the current request, embedding it, and running semantic similarity search against an OpenSearch vector index so differently worded tickets map to the same underlying meaning. It further details that retrieval spans both historical service requests and relevant Fusion Knowledge Base articles, supports drill-down and resolution comparison, and can preserve relationships by associating a new request as a child of an existing one. The author then highlights implementation realities—RAG is configurable and shipped as part of Siebel rather than a separate stack—while cautioning about data quality, performance/compliance tradeoffs introduced by LLM-based summarization, and the importance of treating ranked results as decision support rather than an automatic verdict. Finally, it argues that semantic search compounds over time, making faster resolutions possible as the searchable “solved problems” knowledge grows, and recommends validating it against messy real archives before rollout. Read the full blog for free on Medium. Join thousands of data leaders on the AI newsletter. Join over 80,000 subscribers and keep up to date with the latest developments in AI. From research to projects and ideas. If you are building an AI startup, an AI-related product, or a service, we invite you to consider becoming a sponsor. Published via Towards AI]]></description>
		
		
		
		<media:content url="https://miro.medium.com/v2/resize:fit:700/1*lLA-_Pr73ZQaCoilnyUHzg.png" medium="image"></media:content>
            	</item>
		<item>
		<title>The Repository That Reviews Itself</title>
		<link>https://towardsai.com/p/machine-learning/the-repository-that-reviews-itself</link>
		
		<dc:creator><![CDATA[Dave R - Microsoft Azure &#38; AI MVP☁️]]></dc:creator>
		<pubDate>Thu, 23 Jul 2026 08:04:34 +0000</pubDate>
				<category><![CDATA[Latest]]></category>
		<category><![CDATA[Machine Learning]]></category>
		<category><![CDATA[Towards AI - Medium]]></category>
		<guid isPermaLink="false">https://towardsai.com/p/artificial-intelligence/the-repository-that-reviews-itself</guid>

					<description><![CDATA[Last Updated on July 23, 2026 by Editorial Team Author(s): Dave R &#8211; Microsoft Azure &#038; AI MVP☁️ Originally published on Towards AI. Triage bots, disposable test boxes, pooled API budgets, and a review loop that calls itself, reconstructed from the source. This article walks through the tooling that keeps OpenClaw, one of the largest and fastest-growing repositories on GitHub. I go component by component: the triage bot that reviews every issue and pull request weekly, the remote execution plane, the relay that pools GitHub rate limits across a team, the visual verification layer, the review loop that calls itself until a change is clean, and the crawlers that give agents local, queryable context. The Repository That Reviews ItselfThe article explains an “agent maintenance” architecture for large GitHub repositories where automation is safe because agents can verify their own work: it starts with the premise that agents can’t observe outcomes like a human can (e.g., no screenshots), so the system adds loop-closing components such as vision-based end-to-end verification, a triage bot that proposes changes separately from applying them, and a cadence that re-reviews items until fixes are validated. It then covers the supporting plumbing—repository “contract” files like vision.md and AGENTS.md to define scope and invariants, crawlers that mirror external discussion data into local queryable stores, dashboards and small friction-removing tools, and rate-limit pooling for scalable parallel agents. Finally, it describes recursive review (AutoReview) and larger-repo adaptation (Clawpatch), plus practical distribution and enterprise considerations, ending with the idea that these tools reduce repeated human bottlenecks by turning every irritation into a verifiable closed loop that agents can run. Join thousands of data leaders on the AI newsletter. Join over 80,000 subscribers and keep up to date with the latest developments in AI. From research to projects and ideas. If you are building an AI startup, an AI-related product, or a service, we invite you to consider becoming a sponsor. Published via Towards AI]]></description>
		
		
		
		<media:content url="https://miro.medium.com/v2/resize:fit:640/format:webp/1*6JO45GmtHeU-nagahcbAPg.png" medium="image"></media:content>
            	</item>
		<item>
		<title>Semantic Routing Protocol: How AI Agents Are Starting to Talk to Each Other Directly (Not Through LLMs)</title>
		<link>https://towardsai.com/p/machine-learning/semantic-routing-protocol-how-ai-agents-are-starting-to-talk-to-each-other-directly-not-through-llms</link>
		
		<dc:creator><![CDATA[Rizwanhoda]]></dc:creator>
		<pubDate>Thu, 23 Jul 2026 08:03:07 +0000</pubDate>
				<category><![CDATA[Latest]]></category>
		<category><![CDATA[Machine Learning]]></category>
		<category><![CDATA[Towards AI - Medium]]></category>
		<guid isPermaLink="false">https://towardsai.com/p/artificial-intelligence/semantic-routing-protocol-how-ai-agents-are-starting-to-talk-to-each-other-directly-not-through-llms</guid>

					<description><![CDATA[Last Updated on July 23, 2026 by Editorial Team Author(s): Rizwanhoda Originally published on Towards AI. You’ve built an AI agent that works perfectly in development. Deploy it to production with 30 different SaaS integrations and suddenly your costs are 10x higher and latency is unbearable. Here’s why, and what Semantic Routing fixes. There’s a moment every team building production AI agents hits at exactly the same place. The article argues that production agents break because they use expensive LLMs for routing/tool selection, forcing huge tool definitions into every context and causing high latency, token bloat, and hallucinated API calls. Semantic Routing addresses this by separating routing (classification) from reasoning: a fast vector classifier chooses the right intent/tool path (often in ~100ms), while the main LLM is called only for true reasoning. It explains the concept via “old vs new” flow examples, then situates the approach in timing and infrastructure changes (cost pressure, improved small routing models like vLLM Semantic Router, and emerging standardization such as IETF-backed SIRP and related ecosystem protocols like MCP and A2A). It outlines an architecture where semantic routing sits between user requests and tool selection, compares semantic routing against alternatives (LLM routing, hard-coded rules, multi-stage/hybrid methods), and highlights three practical impacts: a changed agent architecture, making multi-agent systems economically viable, and producing more predictable cost structures for pricing. Finally, it provides actionable steps (evaluate semantic routing once you have many tools, start with vLLM Semantic Router, plan for SIRP compatibility, and monitor cost baselines) and predicts semantic routing will become “table stakes” for serious production agent systems. Join thousands of data leaders on the AI newsletter. Join over 80,000 subscribers and keep up to date with the latest developments in AI. From research to projects and ideas. If you are building an AI startup, an AI-related product, or a service, we invite you to consider becoming a sponsor. Published via Towards AI]]></description>
		
		
		
		<media:content url="https://miro.medium.com/v2/resize:fit:640/format:webp/1*eY_SSMy5JDEJLgfnWpFMRA.png" medium="image"></media:content>
            	</item>
		<item>
		<title>Hermes vs OpenClaw: 2026 Open Source AI Agent Automation Framework Guide</title>
		<link>https://towardsai.com/p/machine-learning/hermes-vs-openclaw-2026-open-source-ai-agent-automation-framework-guide</link>
		
		<dc:creator><![CDATA[Web Researcher]]></dc:creator>
		<pubDate>Thu, 23 Jul 2026 08:02:55 +0000</pubDate>
				<category><![CDATA[Latest]]></category>
		<category><![CDATA[Machine Learning]]></category>
		<category><![CDATA[Towards AI - Medium]]></category>
		<guid isPermaLink="false">https://towardsai.com/p/artificial-intelligence/hermes-vs-openclaw-2026-open-source-ai-agent-automation-framework-guide</guid>

					<description><![CDATA[Last Updated on July 23, 2026 by Editorial Team Author(s): Web Researcher Originally published on Towards AI. AI agents are evolving from simple task assistants into autonomous systems capable of executing processes, calling tools, and optimizing workflows. As trending AI automation frameworks, OpenClaw and Hermes represent two distinct directions: the former focuses on workflow execution and tool collaboration, while the latter emphasizes long-term learning and capability evolution. Rather than a simple case of one replacing the other, they suit different business scenarios. This article compares their core technologies, capability differences, and deployment practices to help users select the right AI automation solution for their specific needs. I. Hermes vs OpenClaw: Core Differences Between the Two AI Automation Frameworks OpenClaw and Hermes represent two distinct evolutionary paths for AI agent automation. OpenClaw is a platform-based AI agent framework designed to connect external tools, services, and data sources, completing automated processes through task orchestration. It is ideal for scenarios with well-defined workflows that require stable execution. Hermes emphasizes long-term memory, task feedback, and capability optimization. It leverages historical experience to improve subsequent task handling and refines its approach based on feedback. This makes it a better fit for long-running, complex analytical, and continuously optimized AI automation scenarios. In short: OpenClaw: Helps AI complete tasks more efficiently, emphasizing automated execution and business implementation. Hermes: Helps AI continuously improve its capabilities, emphasizing learning retention and intelligent evolution. Core differences between OpenClaw and Hermes at a glance: II. Hermes vs OpenClaw: In-Depth Comparison of Core Technical Capabilities 1、Task Planning and Execution Capabilities OpenClaw utilizes a workflow-driven execution model. By using task chains, node management, and tool-calling logic, it breaks complex tasks into multiple steps. Its advantage lies in a clear execution path that is easy to control and debug, making it perfect for automated workflows with explicit rules. Hermes highlights dynamic planning capabilities. Instead of relying completely on preset workflows, it adjusts its execution strategy based on task feedback and historical outcomes. This suits tasks with complex goals and highly variable environments. Core Difference: OpenClaw: Enhances the stability and controllability of task execution. Hermes: Increases the flexibility and adaptability of task handling. 2、Tool Calling and Automation Extension Capabilities OpenClaw leans toward Tool Orchestration. By centrally managing APIs, databases, and third-party services, it allows agents to quickly connect to external capabilities and form complete automated workflows. Hermes focuses more on tool utilization efficiency. It analyzes historical task results to optimize tool selection, calling sequences, and execution strategies, rather than simply increasing the number of connected tools. In short: OpenClaw solves “how to connect more capabilities.” Hermes solves “how to use capabilities more efficiently.” 3、Memory Systems and Continuous Learning Capabilities OpenClaw focuses heavily on context management, saving current task states, execution logs, and workflow information to ensure continuous operation. This approach works well for short-cycle, fixed-workflow automation scenarios. Hermes prioritizes long-term memory. By retaining historical task experiences, it uses past outcomes to optimize future decisions, allowing the agent to progressively upgrade its capabilities during long-term operations. 4、Skill Systems and Task Optimization Capabilities OpenClaw relies on modular extensions. Developers can add features like data collection, file processing, and API calling, allowing the agent to quickly adapt to different business requirements. Hermes emphasizes skill optimization, aiming for the agent to adjust its own capabilities based on execution feedback to increase long-term task efficiency. Therefore, the two correspond to: OpenClaw: Rapidly building business automation systems. Hermes: Exploring continuous-growth agents. 5、Deployment Cost and Maintenance Difficulty From an engineering deployment standpoint, OpenClaw focuses on workflow configuration and system integration. Its deployment cost is relatively low, making it ideal for enterprises looking to launch AI automation tasks quickly. Hermes involves long-term memory, feedback mechanisms, and strategy optimization, which demands higher standards for data management, operational monitoring, and maintenance. Consequently: To quickly achieve AI automation tasks: OpenClaw is easier to implement. To explore self-learning AI agents: Hermes holds more developmental potential. III. AI Agent Deployment Practice: 3 Practical Recommendations 1、Break Down Automation Tasks Reasonably Executing multiple goals simultaneously can easily lead to confused task logic, tool conflicts, and difficult verification. Breaking down tasks reduces the execution pressure on a single agent and improves the stability of automated workflows. Data Collection Agent: Responsible for gathering target data and basic information. Analysis Agent: Responsible for processing data and generating analytical results. Execution Agent: Responsible for calling business tools to complete specific operations. Among these, OpenClaw is better suited for workflow orchestration and tool collaboration, while Hermes is ideal for handling analytical tasks that require long-term optimization. 2、Build a Stable Running Environment Beyond the agent’s inherent task capabilities, AI agents rely heavily on stable data access and network environments during actual operations, especially in multi-platform automation, data collection, and business system connections. Frequent changes in the access environment can trigger request errors, task interruptions, or unstable account statuses. For business operations that require a fixed access environment, dedicated static residential proxies can provide stable IP support. For high-frequency data collection and market analysis tasks, rotating residential proxies can be used to switch nodes. For instance, IPFoxy provides dedicated static residential proxy, ISP residential proxy, and rotating residential proxy services to meet the needs of various AI automation scenarios. It primarily focuses on delivering high-quality, clean proxy resources. Combined with proper device environment configurations, it helps prevent account bans and IP blacklisting issues during automated tasks. 3、Continuously Monitor and Optimize Agent Workflows As business dynamics change and task complexity grows, agents still require continuous adjustments and optimization. This is particularly true for agents with long-term learning capabilities; without effective monitoring, they may accumulate erroneous decisions, drift from task objectives, or experience drops in execution efficiency. Key optimization focus areas include: Monitoring execution results: Analyzing task completion rates, root causes of errors, and anomalous nodes. Optimizing task workflows: Reducing repetitive operations and increasing tool-calling efficiency. Updating knowledge rules: Adjusting execution logic based on market changes and business feedback. Choosing the right solution for different automation scenarios at a glance: IV. FAQ Which is stronger, OpenClaw or Hermes? OpenClaw [&#8230;]]]></description>
		
		
		
			</item>
		<item>
		<title>Real-Time Anomaly Detection With Kafka and Faust: From Stream to Slack Alert in Under 2 Seconds</title>
		<link>https://towardsai.com/p/machine-learning/real-time-anomaly-detection-with-kafka-and-faust-from-stream-to-slack-alert-in-under-2-seconds</link>
		
		<dc:creator><![CDATA[EMMANUEL NWANGUMA]]></dc:creator>
		<pubDate>Thu, 23 Jul 2026 08:02:06 +0000</pubDate>
				<category><![CDATA[Latest]]></category>
		<category><![CDATA[Machine Learning]]></category>
		<category><![CDATA[Towards AI - Medium]]></category>
		<guid isPermaLink="false">https://towardsai.com/p/artificial-intelligence/real-time-anomaly-detection-with-kafka-and-faust-from-stream-to-slack-alert-in-under-2-seconds</guid>

					<description><![CDATA[Last Updated on July 23, 2026 by Editorial Team Author(s): EMMANUEL NWANGUMA Originally published on Towards AI. There’s a category of problem where being right tomorrow is the same as being wrong. A fraudulent transaction clears. A server starts throwing errors at 2pm and nobody notices until the morning report. A sensor drifts out of spec and the machine it’s attached to grinds itself apart over six hours. In every one of those cases the detection logic might be perfect — but if it runs as a nightly batch job, the answer arrives after the damage. So I built the opposite: a streaming pipeline where events flow in continuously, get scored the moment they arrive, and turn into a Slack alert in under two seconds. It handles three genuinely different data types — card transactions, server metrics, and IoT sensor readings — on one pipeline. Along the way I found two bugs that had my LSTM detector performing at 4% recall, and the fix for the second one had nothing to do with the model at all. More on that below. Why batch is the wrong shape for this problem The instinct is to treat anomaly detection as a data science problem: get data, train model, evaluate, ship. But in production it’s mostly a systems problem. Three things matter more than the model: Latency — how long between the event happening and a human knowing. Noise — whether the alerts are still worth reading after a week. Adaptability — whether you can change the detector without taking the system down. A batch job fails all three. It’s slow by construction, it dumps a pile of findings with no grouping, and updating it means a redeploy. The pipeline Data sources: transactions, server metrics, IoT sensors │ ▼ Redpanda topics (Kafka API) anomaly.fraud / anomaly.metrics / anomaly.iot │ ▼ Faust stream processor ├── rolling windows (1m / 5m / 1h, per entity) ├── route event type → detector(s) └── real-time inference │ ┌─────────────────┴─────────────────┐ ▼ ▼ Detection models TimescaleDB ├── Isolation Forest (fraud) (events + flags, ├── LSTM Autoencoder (IoT) hypertables) └── Z-score / EWMA (metrics) │ │ ▼ ▼ Grafana dashboard Alert engine ├── severity scoring ├── deduplication └── Slack + email Redpanda gives me the Kafka API without the JVM. Faust does the stream processing in Python. TimescaleDB stores everything as hypertables so time-bucketed queries stay fast. Grafana reads both TimescaleDB and Prometheus. Rolling windows, and why they’re per-entity A single event usually isn’t enough to judge anything. A £2,000 transaction is unremarkable — unless that card has already made eleven transactions in the last hour. So the stream keeps rolling windows (1 minute, 5 minutes, 1 hour) and derives counts, means, standard deviations, and deltas on top of the raw fields. The subtle part is the key. Windows are kept per source:entity, not per entity: window_key = f&#34;{source}:{event.entity_id}&#34;self._features.add(window_key, event) I found this the hard way. My first version keyed windows by entity_id alone, and a test that reused the same ID across two source types blew up with a KeyError. A server&#39;s window had been filled with fraud features. Scoping by source makes the collision structurally impossible rather than merely unlikely. Three detectors, three different jobs Routing is per source type: ROUTING = { &#34;fraud&#34;: [&#34;isolation_forest&#34;, &#34;zscore&#34;], &#34;metrics&#34;: [&#34;zscore&#34;, &#34;ewma&#34;, &#34;isolation_forest&#34;], &#34;iot&#34;: [&#34;lstm_autoencoder&#34;, &#34;zscore&#34;],} Z-score / EWMA for server metrics. They track a running mean and standard deviation per feature and flag deviations. No training run, no model file, cheap enough to run inline on every event. For high-volume metrics where “normal” is a stable band, this is genuinely hard to beat. Isolation Forest for fraud. Fraud rarely looks wrong on any single dimension — it’s the combination that’s off. A large amount is fine. A foreign transaction is fine. A 3am transaction is fine. All three together on a card that’s already been used eleven times this hour is not. Isolation Forest handles that interaction; a per-feature threshold never will. LSTM Autoencoder for IoT. Sensors produce sequences, and the anomaly is often a pattern rather than a value — a temperature that’s climbing at the wrong rate is a problem long before it crosses any single threshold. The autoencoder learns to reconstruct a window of normal readings; when reconstruction error spikes, the pattern is off. That last one is where things got interesting. Bug #1: the autoencoder that couldn’t detect anything My first backtest of the LSTM came back with 4% recall. It was catching essentially nothing. The cause was in one line of my training setup: I was training the autoencoder on the full labeled dataset — which included the anomalies. An autoencoder detects anomalies by learning to reconstruct normal data well, then flagging inputs it reconstructs badly. The detection threshold is set at, say, the 99th percentile of reconstruction error observed during training. But if 5% of your training data is anomalous, those anomalies produce the largest reconstruction errors, and they drag the 99th-percentile threshold up to their own level. You end up with a threshold that only the most extreme anomalies could ever exceed. The fix is one line, and it’s a methodological rule rather than a tuning trick: # Autoencoders must train on NORMAL data only — training on the# contaminated set pushes the reconstruction-error threshold up to the# anomalies themselves and collapses recall.normal_events = [e for e, lab in zip(events, y_true) if lab == 0]det = train_lstm_autoencoder(normal_events, fn, seq_len=seq_len, epochs=10) Recall went from 0.04 to 1.00. Bug #2: the model was fine, my evaluation was wrong With recall fixed, precision came back at 0.14. The detector was now flagging roughly seven times more windows than there were anomalies. I nearly started tuning the threshold. Then I looked at how I was scoring it. The autoencoder consumes a window of 10 events and produces one verdict about that window. I was comparing that verdict against the label of the last event in the window only. With a 5% anomaly rate and a 10-event window, [&#8230;]]]></description>
		
		
		
			</item>
		<item>
		<title>How MCP Improves External Tooling in Hermes AI Agent Workflows</title>
		<link>https://towardsai.com/p/machine-learning/how-mcp-improves-external-tooling-in-hermes-ai-agent-workflows</link>
		
		<dc:creator><![CDATA[Hoe shi Lee]]></dc:creator>
		<pubDate>Thu, 23 Jul 2026 08:01:24 +0000</pubDate>
				<category><![CDATA[Latest]]></category>
		<category><![CDATA[Machine Learning]]></category>
		<category><![CDATA[Towards AI - Medium]]></category>
		<guid isPermaLink="false">https://towardsai.com/p/artificial-intelligence/how-mcp-improves-external-tooling-in-hermes-ai-agent-workflows</guid>

					<description><![CDATA[Last Updated on July 23, 2026 by Editorial Team Author(s): Hoe shi Lee Originally published on Towards AI. How MCP Improves External Tooling in Hermes AI Agent Workflows Hermes AI Agent is gaining popularity these days as teams explore autonomous, workflow-driven systems for research, automation, and multi-step execution. I’ve used it for its structured planning, persistent memory, and ability to refine workflows through repeated runs. The main issue shows up when workflows depend on multiple external systems. Execution itself is not the problem. The real friction comes from tool integration, where each API has its own authentication flow, response format, and failure behavior. This makes workflows harder to scale and maintain. This is where MCP comes in. It introduces a standard way for agents to interact with external tools, removing the need to handle each integration separately. In this post, I’ll break down how Hermes works internally, why tool integration becomes a bottleneck in real setups, and how MCP changes the way external tooling is handled in agent workflows. What is Hermes AI Agent? Hermes AI Agent is an open-source autonomous agent runtime developed by Nous Research. It is built to run persistent workflows on local machines, servers, or cloud environments, with a focus on long-running, stateful execution rather than isolated prompts. Unlike traditional LLM wrappers, Hermes is structured around continuous task execution. A single goal is decomposed into steps, executed sequentially, and refined based on intermediate outputs. It is not just responding to inputs but actively managing the lifecycle of a task. One of its defining characteristics is its ability to convert completed workflows into reusable skills. After a task finishes, Hermes analyzes what happened, captures the procedure, and stores it as a structured skill. Over time, this creates a growing library of execution patterns that become more refined as the system is used in real workflows. This makes Hermes especially useful for repetitive or evolving operational tasks where consistency improves over time. How Hermes Executes Workflows Internally, Hermes is structured into four tightly connected layers that control how a task moves from intent to completion. The planning layer is responsible for breaking a high-level goal into smaller executable steps. It continuously updates the plan as new information arrives during execution. The execution layer carries out each step and triggers external tool calls when required. The memory layer stores session context, intermediate outputs, and task history in a persistent SQLite-based system with full-text search, which allows workflows to resume or adapt without losing state. The skills layer captures successful workflows as reusable procedures that can be applied to future tasks. These layers operate within a loop that follows a consistent cycle: observe, execute, reflect, and refine. Each completed task feeds back into the system, improving how future tasks are handled. Tool execution is not an external add-on but part of the runtime loop itself. Each step can call external systems, process responses, and pass structured outputs into the next stage of planning. Hermes is model-agnostic, meaning it does not assume a fixed tool ecosystem. Where Hermes Breaks Down in Production Hermes performs well in isolated environments, but production workflows introduce a different set of constraints. The issues rarely come from planning or reasoning. They emerge at the boundaries between Hermes and external systems. One of the first problems is fragmentation. A single workflow often requires multiple tools such as search APIs, ecommerce platforms, or scraping services. Without a shared abstraction layer, each integration introduces a unique handling pattern. Over time, the workflow becomes tightly coupled to the specifics of each tool. Another issue is inconsistent data structures. External tools rarely return data in the same format. Some return structured JSON, others return HTML or loosely formatted text. This forces the workflow to include transformation logic between steps, which increases fragility and makes updates difficult when APIs change. Reliability is another challenge. Rate limits, authentication failures, and endpoint changes all directly impact workflow execution. Since these behaviors differ across tools, the agent has to account for multiple failure modes within the same workflow logic. As the number of tools grows, so does maintenance overhead. Keeping integrations stable starts to require more effort than building the workflows themselves. Debugging also becomes harder because failures can originate from either the agent logic or any of the external systems involved. These issues are not inherent to Hermes. They are a result of handling integration at the agent level rather than at a dedicated infrastructure layer. How to Connect MCP with Hermes AI Agent To avoid managing multiple tool integrations separately, MCP is used as a unified layer between Hermes and external systems. For this setup, I’ve used MCP360 to connect MCP with Hermes AI Agent, since it provides a single gateway for all tool interactions. The steps below show how to set up the connection and verify that Hermes is correctly using MCP-based tools. Step 1. Copy Your MCP360 Gateway URL Log in to your MCP360 dashboard and open an existing project or create a new one. From the left navigation menu, open MCP Servers. You can either select a specific MCP server or use the Universal MCP Gateway, which provides access to all tools available in your MCP360 workspace. Copy the MCP Gateway URL. You will use this endpoint when configuring tool access inside Hermes AI Agent. Step 2. Install Hermes AI Agent Open Windows PowerShell as Administrator and run: Instead of manually running commands, you can also use an AI coding assistant like Codex or Cursor AI to execute the setup for you. In Codex, enter the following prompt to install Hermes AI Agent: Install Hermes AI Agent on this Windows machine using the official installation method. After confirming the installation, the next step is to connect Hermes to the MCP360 Gateway URL copied earlier. Step 3. Start Hermes Chat and Connect MCP360 Open a new terminal window in Windows PowerShell and start the Hermes chat interface: After adding the MCP360 Gateway URL and token, Hermes confirms that the MCP [&#8230;]]]></description>
		
		
		
		<media:content url="https://miro.medium.com/v2/resize:fit:700/1*KhSXjY8IVQF-duLGkzAoJA.png" medium="image"></media:content>
            	</item>
		<item>
		<title>Anthropic Just Exposed Claude Code’s Biggest Weakness. The Fix Takes Only 6 Lines.</title>
		<link>https://towardsai.com/p/machine-learning/anthropic-just-exposed-claude-codes-biggest-weakness-the-fix-takes-only-6-lines</link>
		
		<dc:creator><![CDATA[Anup Karanjkar]]></dc:creator>
		<pubDate>Thu, 23 Jul 2026 08:00:31 +0000</pubDate>
				<category><![CDATA[Latest]]></category>
		<category><![CDATA[Machine Learning]]></category>
		<category><![CDATA[Towards AI - Medium]]></category>
		<guid isPermaLink="false">https://towardsai.com/p/artificial-intelligence/anthropic-just-exposed-claude-codes-biggest-weakness-the-fix-takes-only-6-lines</guid>

					<description><![CDATA[Last Updated on July 23, 2026 by Editorial Team Author(s): Anup Karanjkar Originally published on Towards AI. Opus 4.8 quietly admits AI struggles to catch its own bugs. The real breakthrough isn’t a smarter model — it’s making another AI review code it never wrote. Read Anthropic’s own line about their best coding model closely and it stops sounding like a feature and starts sounding like an admission. After noting Anthropic’s “four times less likely” claim is a reduction, not an elimination, the author argues that self-review fails because the model can’t “proofread the window it wrote in”—it reviews code through the intent it had while generating it. The article then explains the workaround Claude Code provides: create a read-only “verifier” subagent that runs in a fresh, isolated context window so it reviews the git diff without seeing the conversation history or what the original author already read. The author walks through a concrete example where a nested-config merge bug passes a simplistic test but gets caught by the verifier, and shows that the fix can be “one line” logic (recursive merge). Finally, it covers how to make verification non-optional using a Stop hook (paired with tests) and cautions about trusting internal metrics, the tendency of gap-seeking reviewers to invent issues, and the importance of fresh context over simply using a smarter model. Read the full blog for free on Medium. Join thousands of data leaders on the AI newsletter. Join over 80,000 subscribers and keep up to date with the latest developments in AI. From research to projects and ideas. If you are building an AI startup, an AI-related product, or a service, we invite you to consider becoming a sponsor. Published via Towards AI]]></description>
		
		
		
		<media:content url="https://miro.medium.com/v2/resize:fit:700/1*BUVovXAe-HAA2nr3WN_C5w.png" medium="image"></media:content>
            	</item>
		<item>
		<title>Kimi K3: The Chinese Model That Just Beat Claude at Its Own Game</title>
		<link>https://towardsai.com/p/machine-learning/kimi-k3-the-chinese-model-that-just-beat-claude-at-its-own-game</link>
		
		<dc:creator><![CDATA[MayhemCode]]></dc:creator>
		<pubDate>Thu, 23 Jul 2026 07:55:48 +0000</pubDate>
				<category><![CDATA[Latest]]></category>
		<category><![CDATA[Machine Learning]]></category>
		<category><![CDATA[Towards AI - Medium]]></category>
		<guid isPermaLink="false">https://towardsai.com/p/artificial-intelligence/kimi-k3-the-chinese-model-that-just-beat-claude-at-its-own-game</guid>

					<description><![CDATA[Last Updated on July 23, 2026 by Editorial Team Author(s): MayhemCode Originally published on Towards AI. China Beat America’s Best Coding AI, and Almost Nobody Saw It Coming On July 16 2026, most of the western developers never think of this will ever happen, like a model released one year ago jumped from 18th place to first place in one of the industry’s top coding leaderboards. as this happened engineers from San Francisco to Singapore were in a dilemma that American AI lead is gone or what happened to it. After the initial announcement, the article explains how Moonshot AI’s Kimi K3 achieved a major leap on real coding leaderboards—highlighting its scale (a 2.8T MoE model) alongside specific benchmark and leaderboard results—then focuses on why open-weight availability is driving panic and attention. It details K3’s scheduled release of full weights, its mixture-of-experts design (using only a small fraction of experts per token) to keep inference costs manageable, and its pricing versus frontier competitors, while also noting a key tradeoff: limited “max” reasoning settings and a fast token burn, plus a reported increase in hallucination/accuracy tradeoffs. The piece further describes architectural changes aimed at improving reasoning efficiency, a “chip design” demo used to show broader capability beyond web coding, and background on Moonshot AI’s funding, the broader Kimi product ecosystem, and the reaction from developers and investors. Overall, it frames K3 as a strong open-coding option that challenges the assumption of a multi-year closed-frontier lead, but advises teams to validate it on their own codebases and keep human checks where factual correctness matters. Read the full blog for free on Medium. Join thousands of data leaders on the AI newsletter. Join over 80,000 subscribers and keep up to date with the latest developments in AI. From research to projects and ideas. If you are building an AI startup, an AI-related product, or a service, we invite you to consider becoming a sponsor. Published via Towards AI]]></description>
		
		
		
		<media:content url="https://miro.medium.com/v2/resize:fit:1000/1*mU-Ke8O7gI9rC2zRO_p3Rg.png" medium="image"></media:content>
            	</item>
		<item>
		<title>If AI Can Clone Your App in a Day, What Is Left to Defend?</title>
		<link>https://towardsai.com/p/machine-learning/if-ai-can-clone-your-app-in-a-day-what-is-left-to-defend</link>
		
		<dc:creator><![CDATA[Dave R - Microsoft Azure &#38; AI MVP☁️]]></dc:creator>
		<pubDate>Thu, 23 Jul 2026 07:48:03 +0000</pubDate>
				<category><![CDATA[Latest]]></category>
		<category><![CDATA[Machine Learning]]></category>
		<category><![CDATA[Towards AI - Medium]]></category>
		<guid isPermaLink="false">https://towardsai.com/p/artificial-intelligence/if-ai-can-clone-your-app-in-a-day-what-is-left-to-defend</guid>

					<description><![CDATA[Last Updated on July 23, 2026 by Editorial Team Author(s): Dave R &#8211; Microsoft Azure &#038; AI MVP☁️ Originally published on Towards AI. Software moats, agent architectures, and the engineering that still holds value when the cost of building drops to almost zero. This article looks at software defensibility in a world where AI can generate working code almost for free. We start with a simple question: if building software costs almost nothing, what still gives it value, and then work through the classic moats of data, brand, distribution, and expertise to see which ones hold and which ones leak. From there it gets practical: how latency budgets shape voice pipelines, why human preference is hard to encode, how spec-driven development and Model Context Protocol change the way we build, and what irreversibility means once an agent can touch a database or a motor. If AI Can Clone Your App in a Day, What Is Left to Defend?After the introduction, the article argues that when software creation becomes nearly free, “replicability” undermines many traditional moats: proprietary data and encoded expertise commoditize, trust/branding becomes transient as capabilities leap, and distribution can be purchased or recreated—leaving only momentum as potentially durable, though it creates a constant treadmill. The pivot is that defensible value shifts to the long tail, where underserved languages, real-time voice latency budgets, and culturally specific preference/turn-taking are harder to generalize; quality there depends on evaluation, data, and pipeline engineering rather than just prompting a model. It then expands from product strategy to agent architecture, emphasizing that workflows still rely on legacy tooling, so teams should redesign development surfaces (hybrid terminal/IDE), handle persistence via managed runtimes, and protect the true artifact—specifications/instructions—through spec-driven development. Finally, it highlights the broader “environment lever” (modular codebases, API-first design, Model Context Protocol) and the crucial safety property of irreversibility, showing why guardrails and confirmation are needed as agents gain physical/digital action capability, ending with practical advice for builders and career defensibility. Read the full blog for free on Medium. Join thousands of data leaders on the AI newsletter. Join over 80,000 subscribers and keep up to date with the latest developments in AI. From research to projects and ideas. If you are building an AI startup, an AI-related product, or a service, we invite you to consider becoming a sponsor. Published via Towards AI]]></description>
		
		
		
		<media:content url="https://miro.medium.com/v2/resize:fit:700/1*xu5UF3n-LE9_-PFcGbsdow.png" medium="image"></media:content>
            	</item>
		<item>
		<title>Logistic Regression: The Tutorial That Starts Where Others End</title>
		<link>https://towardsai.com/p/machine-learning/logistic-regression-the-tutorial-that-starts-where-others-end</link>
		
		<dc:creator><![CDATA[Felix Pappe]]></dc:creator>
		<pubDate>Thu, 23 Jul 2026 07:47:44 +0000</pubDate>
				<category><![CDATA[Latest]]></category>
		<category><![CDATA[Machine Learning]]></category>
		<category><![CDATA[Towards AI - Medium]]></category>
		<guid isPermaLink="false">https://towardsai.com/p/artificial-intelligence/logistic-regression-the-tutorial-that-starts-where-others-end</guid>

					<description><![CDATA[Last Updated on July 23, 2026 by Editorial Team Author(s): Felix Pappe Originally published on Towards AI. Go inside the training loop and watch the model learn If you’ve ever wondered what statistics packages and programs are doing when calculating logistic regression, this is for you. The logistic (sigmoid) function transforms a linear input into a probability, separating binary data points into class 0 and class 1.The article walks through how logistic regression turns inputs into probabilities using the sigmoid function, framing the learning problem as maximizing likelihood (and minimizing the resulting cross-entropy/binary log-loss). It then derives the gradient needed for optimization, explains how gradient descent updates model parameters iteratively using a learning rate, and connects each math step to an example “online shop” dataset. Finally, it illustrates the first parameter update and how repeating updates over many iterations makes the learned sigmoid curve better match the data, including why input standardisation improves training stability and how to convert learned parameters back to the original feature scale for interpretation. Read the full blog for free on Medium. Join thousands of data leaders on the AI newsletter. Join over 80,000 subscribers and keep up to date with the latest developments in AI. From research to projects and ideas. If you are building an AI startup, an AI-related product, or a service, we invite you to consider becoming a sponsor. Published via Towards AI]]></description>
		
		
		
		<media:content url="https://miro.medium.com/v2/resize:fit:700/1*yOqGYg7ezfnHGIp3wQLBiw.png" medium="image"></media:content>
            	</item>
	</channel>
</rss>
