Day 22: Multi-Agent Collaboration (Manager–Worker Model) 🤝🤖

Executive Summary

Single-agent systems hit a ceiling very quickly.

They struggle when:

  • tasks are large and multi-disciplinary 🧩
  • parallelism matters ⏱️
  • different skills require different reasoning styles

Multi-agent systems address this by splitting cognition across specialized agents.

The most practical and production-tested pattern today is the Manager–Worker model.

This chapter explains:

  • why multi-agent collaboration exists
  • how the Manager–Worker pattern actually works
  • when it succeeds and when it fails
  • how to implement it with real code

This is not about agent swarms or emergent chaos.

It’s about controlled delegation.

Why Single Agents Break Down 🚧

Consider a task like:

“Analyze customer churn, identify root causes, propose fixes, and estimate business impact.”

A single agent must:

  • reason across data analysis 📊
  • understand product context 🧠
  • think strategically 🎯
  • communicate clearly ✍️

This overload causes:

  • shallow reasoning
  • skipped steps
  • brittle outputs

Humans don’t work this way — teams do.

Multi-agent systems mirror organizational design.

What Is the Manager–Worker Model? 🧠➡️🛠️

At a high level:

  • Manager Agent: plans, delegates, evaluates
  • Worker Agents: execute specialized tasks
User Request
     ↓
 Manager Agent
     ↓
┌───────────┬───────────┬───────────┐
 Worker A   Worker B    Worker C
 (Data)     (Research)  (Strategy)
└───────────┴───────────┴───────────┘
     ↓
 Manager Synthesizes
     ↓
 Final Output

Key idea:

The manager never does the work — it orchestrates it.

Responsibilities by Role 🎭

Manager Agent

  • clarify intent
  • decompose tasks
  • assign workers
  • validate results
  • resolve conflicts

Worker Agents

  • execute narrowly scoped tasks
  • use tools heavily
  • return structured outputs

This separation prevents cognitive overload.

Why This Pattern Works So Well ✅

The Manager–Worker model succeeds because it:

  • enforces explicit planning 🧠
  • enables parallel execution ⚡
  • isolates failures 🔥
  • improves debuggability 🔍

One worker can fail without collapsing the system.

Real-World Use Cases 🌍

1️⃣ Software Development Agents

Manager:

  • reviews requirements
  • assigns coding, testing, documentation

Workers:

  • Code Agent
  • Test Agent
  • Review Agent

2️⃣ Research & Analysis

Manager:

  • decomposes research question

Workers:

  • Source Finder
  • Evidence Extractor
  • Contradiction Detector

3️⃣ Customer Support Escalation

Manager:

  • triages ticket

Workers:

  • Knowledge Base Agent
  • Log Analysis Agent
  • Resolution Draft Agent

Failure Modes Unique to Multi-Agent Systems 🚨

Failure What Happens
Over-delegation Manager creates too many workers
Under-specification Workers don’t know success criteria
Conflict Workers disagree with no resolution
Coordination overhead More agents, less progress

Multi-agent systems amplify design mistakes.

Designing a Good Manager Agent 🧠🎯

The manager prompt is critical.

Bad manager:

“Solve the problem using other agents.”

Good manager:

  • defines success
  • defines constraints
  • defines output schema

Example: Manager Prompt (Simplified)

You are a Manager Agent.

Your responsibilities:
1. Clarify the goal
2. Break it into subtasks
3. Assign each subtask to the best worker
4. Validate worker outputs
5. Produce a final synthesis

Rules:
- Do not execute tasks yourself
- Ask workers for structured outputs
- Resolve disagreements explicitly

This single prompt changes system behavior dramatically.

Worker Prompt Template 🛠️

You are a specialized Worker Agent.

Task:
- Execute ONLY the assigned subtask

Constraints:
- Do not make assumptions outside scope
- Cite evidence where applicable
- Return output in JSON format

Workers should be boring and predictable.

Code Example: Manager–Worker with LangGraph 🧩💻

from langgraph.graph import StateGraph

class State(dict):
    pass

# Define manager logic
def manager(state):
    tasks = [
        {"agent": "data_worker", "task": "Analyze churn data"},
        {"agent": "research_worker", "task": "Find industry benchmarks"}
    ]
    return {"tasks": tasks}

# Define worker logic
def data_worker(state):
    return {"data_analysis": "Churn increased 12% among SMB users"}

def research_worker(state):
    return {"benchmarks": "Industry churn avg is 8–10%"}

# Build graph
graph = StateGraph(State)
graph.add_node("manager", manager)
graph.add_node("data_worker", data_worker)
graph.add_node("research_worker", research_worker)

graph.set_entry_point("manager")

This is a simplified illustration — real systems include validation and retries.

Conflict Resolution Strategy ⚖️

When workers disagree:

  • manager compares evidence
  • requests clarification
  • escalates uncertainty to humans if needed

Never average conflicting answers.

Observability in Multi-Agent Systems 👀📊

Log:

  • task assignments
  • worker outputs
  • disagreements
  • retries

Visual traces help debug coordination issues.

Cost & Performance Considerations 💸⚙️

Multi-agent ≠ free.

Costs increase due to:

  • multiple LLM calls
  • coordination overhead

Mitigations

  • reuse workers
  • cache intermediate results
  • cap delegation depth

Case Study: Multi-Agent PR Review System 🧑‍💻📦

Setup

  • Manager agent
  • Code Quality worker
  • Security worker
  • Test Coverage worker

Outcome

  • higher review quality
  • fewer production bugs
  • faster merges

Key insight

Specialists beat generalists.

When NOT to Use Multi-Agent Systems 🚫

Avoid when:

  • task is simple
  • latency is critical
  • coordination cost outweighs benefits

Sometimes one good agent is enough.

Final Takeaway

The Manager–Worker model works because it:

  • mirrors human collaboration 🤝
  • enforces structure 🧠
  • scales reasoning responsibly 📈

Multi-agent systems are not about more agents.

They are about better division of cognitive labor.

Test Your Skills

🚀 Continue Learning: Full Agentic AI Course

👉 Start the Full Course: https://quizmaker.co.in/study/agentic-ai

I Failed Two Startups, Moved to a New Country, and Spent 10 Years in Tech Before Building Something I Finally Believe In

I Failed Two Startups, Moved to a New Country, and Spent 10 Years in Tech Before Building Something I Finally Believe In

This isn’t a product launch post. This is the story of how FileSyncAI happened — and why I almost didn’t build it.

I came to the United States in 2015 with a B.Tech degree from a tier-3 university in India and a belief that hard work could close any gap. No brand name on my resume. No connections. Just code and stubbornness.

I did my Master’s, and then I did what every immigrant in tech does — I put my head down and worked. For almost 10 years, I’ve been in the trenches. Full stack development. Backend engineering. Machine learning. AI engineering. I didn’t just pick one lane — I drove through all of them. Not because I was confused, but because I was hungry to understand how systems really work, end to end.

But here’s what no one tells you about 10 years of experience — it doesn’t automatically make you confident. It just gives you more context for your doubts.

The Two Startups That Failed

FileSyncAI is not my first startup. It’s my third.

The first two, I built with friends. We had excitement, late-night coding sessions, and big ideas. What we didn’t have was clarity. We didn’t know who we were building for. We didn’t validate the problem deeply enough. We assumed if we built something cool, people would come.

They didn’t.

Both startups failed. Not dramatically — just quietly. The energy died. The users never showed up. We moved on.

I went back to my day job. But the itch never left. I kept thinking — what if I tried again, but this time with a real problem? Not a cool idea, but a painful one. Something I’d seen with my own eyes.

The Moment That Changed Everything

In 2025, I was deep in the staffing and recruitment world. And I saw something that made no sense to me.

Staffing firms — companies whose entire business is placing people in jobs — were spending 50 to 60 percent of their day on manual, repetitive work. Their recruiters weren’t recruiting. They were copying and pasting. Uploading resumes to portals. Chasing emails. Following up on feedback that never came. Manually tracking which consultant applied where, who got shortlisted, who had an interview, who got ghosted.

I thought — this is insane. These are talented people doing data entry.

So I started building a simple system. A way for staffing firms to track consultant activity in real time — applications, shortlists, interview outcomes — without the endless calls and manual updates.

It worked. The operational visibility improved. But something bigger hit me.

The hiring process itself was broken. Not just the tracking. Everything.

The Problem Is Bigger Than I Thought

I started looking at hiring from every angle. And every angle was painful.

Companies post jobs on LinkedIn, Indeed, and five other platforms. They wait weeks. They drown in hundreds of resumes — most of them irrelevant. By the time they shortlist and schedule interviews, the best candidates have already accepted offers somewhere else. Speed kills in hiring, and most companies are slow.

Staffing firms have skilled consultants sitting on their bench. But their recruiters spend the entire day manually applying to jobs, sending follow-up emails, chasing rate confirmations, and begging for interview feedback. The actual work that matters — building client relationships, understanding candidate strengths — never gets done. And their consultants lose opportunities because there’s no proper time management, no system, no workflow.

Candidates — this one hit me the hardest. Every day, people who are desperately looking for jobs spend 2 to 3 hours just applying. Updating resumes. Tailoring cover letters. And then what? Silence. 50 to 60 percent of companies never even send feedback. And when they do, it’s a generic “we decided to go with another candidate.” No explanation. No insight. No way to improve.

I’ve been that candidate. Most of us have. You apply, you wait, you hear nothing, and slowly your confidence drains away. You start wondering — is it my resume? My skills? My background? You don’t know, because nobody tells you.

That’s not just inefficient. That’s disrespectful.

The Wrappers Aren’t Fixing It

I looked at what was already out there. There are tools that auto-apply to jobs based on your resume. Dozens of them. And I asked myself — what’s the outcome? What’s the success rate?

The answer: almost nothing changes. You’re still in the same loop. Apply, wait, hear nothing. The volume goes up, but the quality stays the same. No momentum. No real progress.

Because the problem isn’t applying faster. The problem is that the entire hiring workflow — from job posting to final decision — is disconnected, manual, and opaque. No single tool was fixing the whole chain.

That’s when I knew what I had to build.

Building FileSyncAI — Alone, Scared, and Committed

I spent half a year building FileSyncAI. Alone. After work, on weekends, during every spare hour I could find.

There were nights I stared at my screen and thought — am I fooling myself? I’ve failed twice before. What makes this different? The market is crowded. Bigger companies have more money, more people, more reach. Who am I to think I can fix hiring?

But every time I wanted to quit, I’d remember those staffing firms wasting their days on copy-paste work. I’d remember candidates applying to hundreds of jobs and hearing nothing back. I’d remember that the pain was real — I’d lived it, I’d seen it, I’d heard it from dozens of people.

So I kept building.

What FileSyncAI Actually Does

FileSyncAI brings everyone — companies, staffing firms, and candidates — onto one platform. And then it automates the painful parts.

Here’s how it works:

A company posts a job once. That’s it. From that moment, our Job Automation Agent takes over. It searches across every candidate connected to the platform — staffing firm consultants and individual professionals. It shortlists the best matches based on skills, experience, visa status, and location. It automatically sends email outreach to shortlisted candidates.

Candidates receive the notification, schedule their first-round interview at a time that works for them, and join when it’s time. Our AI agent conducts the interview in real time — based on the resume and job description, it doesn’t go outside the scope. During the interview, we monitor every action and provide complete insights.

Results are delivered instantly. To everyone. Companies can make faster decisions for next rounds. Candidates get detailed feedback immediately — they learn exactly where they stood, what went well, and where they need to improve. No more waiting weeks. No more guessing.

Every user — companies, staffing firms, and individual candidates — gets their own dedicated dashboard where they can see everything happening in real time.

The goal is simple: build trust between every layer of the hiring process. Less bias. Less delay. More quality. More transparency.

And the system learns. Every interview it conducts makes it smarter. Over time, it stops relying on resumes alone and starts matching based on how candidates actually perform. Real data. Real performance. Not just keywords on a page.

Six Agents, One Platform

FileSyncAI isn’t just one tool. It’s an ecosystem of six AI agents:

Live now: The Job Automation Agent — end-to-end hiring, fully automated.

Coming soon: A Job Application Agent that applies to matching jobs on behalf of staffing firms and candidates. An Email Intelligence Agent that reads context and drafts professional responses. A Mock Interview Agent that gives candidates real practice with real-time coaching. A Sync Agent for 24/7 team support. And an Analytics & Insights Agent that tracks performance and improves outcomes continuously.

One platform. Six agents. Built for everyone at the hiring table.

We Are Not Replacing Recruiters

I want to be clear about this. FileSyncAI is not here to replace recruiters. Recruiters bring judgment, context, relationships, and human understanding that no AI can replicate.

What we’re replacing is the manual, repetitive, soul-crushing work — posting on multiple platforms, screening hundreds of resumes, coordinating schedules, chasing feedback. The work that keeps good recruiters from doing what they’re actually great at.

AI handles the operations. Humans handle the judgment. That’s how it should be.

Where I Am Today — Honest and Unfiltered

I launched the beta 5 days ago. Here’s where I stand:

Two early-stage startups have joined. One staffing firm is on board. Six individual professionals have signed up. I have my first company call today.

These aren’t big numbers. I know that. When I scroll through Instagram and see other founders celebrating thousands of users and viral launches, a part of me panics. I wonder if I’m behind. I wonder if I’m building something nobody wants. I wonder if the third time is just going to be the third failure.

But then I come back to the problem. And the problem is real. I’ve had strangers on Reddit tell me — “the pain is real on all three sides.” I’ve had people ask thoughtful questions about the product. I’ve had someone suggest a feature that we already built, which means we’re thinking in the right direction.

I’m not where I want to be. But I’m not where I started either.

What I’ve Learned From Failing Twice

If my two failed startups taught me anything, it’s this:

Build for a real problem, not a cool idea. My first two startups were solutions looking for problems. FileSyncAI started with the problem.

Talk to people before you build. I spent months understanding the pain from every side — companies, staffing firms, candidates — before writing a single line of code.

Don’t wait for perfect. The beta isn’t perfect. There are bugs, rough edges, and features I haven’t built yet. But it’s live. People are using it. And every piece of feedback makes it better.

Do it for the right reasons. I’m not building FileSyncAI because I want to be a founder. I’m building it because I genuinely believe hiring should be fair, fast, and transparent for everyone involved. Especially for the candidates who’ve been ignored for too long.

Our Goal

We’re trying to build trust between every layer of hiring. We want to reduce human errors, eliminate unnecessary delays, and give the right opportunity to the people who work hard for it.

Hiring shouldn’t feel like guesswork. It should be fair, structured, and insightful — for everyone.

Join Us

FileSyncAI is in free beta right now. If you’re a company tired of slow hiring, a staffing firm drowning in manual work, or a candidate who’s sick of applying into silence — I built this for you.

Come see what we’re building. Help us shape it. Tell us what’s missing. Tell us what’s broken. Your feedback isn’t just welcome — it’s the reason we’ll get better.

Join the waitlist: https://www.filesync-ai.com

I failed twice. I moved across the world. I spent a decade learning how to build things. And now I’m building the thing I wish existed when I was on the other side of a broken hiring process.

This time feels different. Not because I’m more confident — but because the problem is more real.

If this story resonated with you, share it with someone who’s felt the pain of hiring — from any side. And if you have feedback, I’m all ears. That’s how we get better.

Hiring #HRTech #Recruitment #Startup #AI #FounderJourney #BuildingInPublic #FileSyncAI

A Beginner’s Guide to ClickHouse in Ruby on Rails

When you build a standard Rails app, PostgreSQL (or MySQL) is your best friend. It handles your users, your posts, and your billing perfectly.

But what happens when you want to track analytics? Let’s say you want to track every single time a user clicks a button, views a page, or triggers an API event. Very quickly, you will have millions (or billions) of rows.

If you try to run Event.where(action: 'click').count on a PostgreSQL table with 50 million rows, your database will choke, your app will slow down, and your users will get annoyed.

This is where ClickHouse comes in.

What is ClickHouse and Why Use It?

ClickHouse is an open-source database specifically built for analytics. It is ridiculously fast. Queries that take 30 seconds in Postgres can take 0.05 seconds in ClickHouse.

How does it do this? It stores data by Columns, not by Rows.

  • Postgres (Row-based): If you ask Postgres to sum up the price of all orders, it pulls every single order row from the hard drive, looks at the price, and adds it up. It loads a lot of unnecessary data into memory.
  • ClickHouse (Column-based): ClickHouse stores all the prices together in one tight file. If you ask it to sum the prices, it grabs just that one file and does the math instantly.

Important Note: You do NOT replace Postgres with ClickHouse. You use them together. Postgres is for your core app data (which needs frequent updates). ClickHouse is for “append-only” data like logs, events, and analytics, where you just insert data and rarely update or delete it.

Here is how to set it up in your Rails app.

STEP 1: The Gem

To make ClickHouse talk to Rails, we don’t have to write raw SQL. We can use ActiveRecord! We just need a special database adapter.

Add this to your Gemfile:

gem 'clickhouse-activerecord'

and run bundle install.

STEP 2: Database Configuration

Next, we need to tell Rails how to connect to ClickHouse. We will use Rails’ built-in multiple database support.

Open your config/database.yml and add a new database connection alongside your primary one.

# config/database.yml
default: &default
  adapter: postgresql
  # ... your normal postgres settings

development:
  primary:
    <<: *default
    database: my_app_development

  # Add the ClickHouse connection here
  clickhouse:
    adapter: clickhouse
    database: my_app_analytics_development
    host: localhost
    port: 8123

STEP 3: Create a Base Model

We don’t want our normal models (like User) saving to ClickHouse. We only want our analytics models to go there.

To do this, we create a new Base class. All our ClickHouse models will inherit from this instead of ApplicationRecord.

Create a new file app/models/clickhouse_record.rb:

class ClickhouseRecord < ActiveRecord::Base
  self.abstract_class = true

  # Tell Rails to send all queries for this class to the ClickHouse DB
  connects_to database: { writing: :clickhouse, reading: :clickhouse }
end

STEP 4: Create your Analytics Model

Now let’s say we want to track Page Views. We create a model that inherits from our new ClickhouseRecord.

# app/models/page_view.rb
class PageView < ClickhouseRecord
  # ClickHouse tables don't usually have a standard 'id' primary key
  self.primary_key = 'date' 
end

Note: You will need to create the actual table in ClickHouse. The clickhouse-activerecord gem does support Rails migrations, but the syntax is a bit different because ClickHouse uses different table engines (like MergeTree). You can read the gem’s docs for the exact migration syntax.

STEP 5: Start Querying!

That’s pretty much it. Now you can use standard ActiveRecord methods to query millions of rows in milliseconds.

You can insert data just like normal:

PageView.create(
  user_id: 1, 
  path: '/pricing', 
  browser: 'Chrome', 
  created_at: Time.now
)

And you can query it extremely fast:

# This will be blazing fast even with 100 million rows
chrome_users = PageView.where(browser: 'Chrome').count

# Grouping and aggregating is what ClickHouse does best
views_by_path = PageView.group(:path).count

Summary

If your app is small, just stick to PostgreSQL. But the moment you start building dashboards, tracking user clicks, or storing massive amounts of API logs, standard databases will become your biggest bottleneck.

Setting up ClickHouse alongside your Rails app takes a bit of work, but it completely solves the “too much data” problem. It lets you keep the nice ActiveRecord syntax while getting enterprise-level analytics speed.

I Built an MCP That Publishes Your Blog to Every Platform With One Sentence to Claude

This is a submission for the Notion MCP Challenge

What I Built

Every developer I know has the same problem. They write a solid post, spend 20 minutes formatting it for Dev.to, copy-paste to Hashnode, re-upload the images that broke because Notion’s CDN URLs expire, then give up on Medium entirely. The writing was the easy part. The publishing killed the momentum.

BlogCast MCP fixes that.

It’s an open-source MCP server + dashboard that turns Notion into a publishing hub. Write once — in Notion or in the built-in rich text editor — then tell Claude to publish it everywhere.

"Publish my TypeScript post to Dev.to and Hashnode"

That’s it. One sentence. Done.

What it actually does:

  • Publishes to Dev.to, Hashnode, and Medium simultaneously
  • Handles Notion’s expiring image URLs automatically (downloads → caches → re-uploads to each platform’s CDN)
  • Adapts content per platform — Medium gets clean HTML, Dev.to/Hashnode get optimized Markdown
  • Syncs analytics back into Notion (views, reactions, comments — all in one place)
  • Schedules posts via Claude: “Schedule my React post for tomorrow at 9am UTC”
  • AI pre-publish checks — catches missing excerpts, vague titles, broken formatting before you hit send
  • Auto-configures Claude Desktop — no JSON editing required

The whole thing runs locally. No third-party servers, no SaaS fees, no data leaving your machine. Your API keys are stored encrypted on your device.

Video Demo

Show us the code

GitHub: github.com/TheCodeDaniel/blogcast_mcp

Built as a proper monorepo — three packages that work together:

Package What it does
mcp/ MCP server — the Claude integration layer
server/ Express backend — publishing, image caching, AI, scheduling
client/ React dashboard — write, publish, manage everything visually

Stack: TypeScript, Node.js, Express, React, Vite, TipTap editor, Anthropic SDK, Notion API.

How I Used Notion MCP

Notion sits at the center of this whole thing — not as a passive database, but as the living CMS.

The MCP server talks to Notion directly via @notionhq/client. When Claude calls publish_post, the server reads the Notion page blocks, converts them to Markdown using notion-to-md, handles all the images, pushes to each platform, then writes the results back into Notion — a linked Analytics database that tracks views, reactions, and comments per platform.

The Notion integration does five specific things:

  1. Posts database — every draft, scheduled post, and published article lives here. Status, tags, platforms, canonical URL — all tracked as Notion properties.

  2. Analytics database — a relational table linked to Posts. Every publish result is logged: URL, status (Success/Failed), and synced stats from each platform’s API.

  3. Auto-migration — on first run, BlogCast patches both databases automatically. New user? You don’t set up a single column manually. Just share your databases with the integration and BlogCast does the rest.

  4. Two-way sync — sync_analytics pulls the latest numbers from Dev.to and Hashnode back into Notion. Your post performance dashboard lives where you already work.

  5. Scheduling — set Scheduled At in Notion (or via Claude: “schedule this for Friday 9am”), and the backend polls every N minutes to auto-publish when the time comes.

The MCP layer is what makes Claude feel like a natural publishing assistant rather than a chatbot bolted onto a dashboard. You’re not filling out forms — you’re just talking.

“Show me what’s in Review” → list_drafts
“Preview my latest draft” → preview_post
“Publish the TypeScript one to all platforms” → publish_post
“What’s the view count on my last post?” → sync_analytics + get_publish_status

Everything that used to take 30 minutes of copy-paste and re-uploading now takes one message.

I Built an AI Mock Test Platform Using Free APIs — Here’s What Works and What Breaks

I’m a student, and I noticed something:

Most people don’t fail exams because they don’t study.
They fail because they don’t practice enough.
So instead of making another “notes app”, I built an AI-powered mock test platform

What It Does

  • Generates mock tests instantly
  • Evaluates answers
  • Identifies weak areas

Tech Stack

  • Frontend: Next.js (Vercel)
  • Backend: Supabase
  • Database/Auth: Supabase
  • AI: Groq API (free-tier models)

This is still an MVP so feel free to suggest any improvements.

OpenClaw’s Credential Problem Is Structural, Not Incidental

Between January 27 and February 3, 2026, three critical security incidents hit OpenClaw:

  • 341 malicious skills discovered in ClawHub marketplace (12% of registry)
  • 1.5 million agent API tokens exposed via Moltbook social network breach
  • 21,639 publicly exposed OpenClaw instances identified by Censys
  • One-click RCE vulnerability (CVE-2026-25253, CVSS 8.8) disclosed

OpenClaw has 250,000+ GitHub stars in 60 days—the fastest-growing open-source project in history. The scale of adoption makes this vulnerability pattern consequential.

Where Credentials Are Stored

OpenClaw stores API keys and bot tokens in plaintext JSON files at ~/.openclaw/openclaw.json. This is documented in official docs and acknowledged in community discussions.

A critical bug (#9627) revealed that config write operations resolve environment variable references like ${VAR_NAME} and replace them with actual credential values in plaintext JSON. Users attempting environment variable indirection discovered that routine updates permanently exposed raw API keys.

Additional risk: the models-config.ts file writes API key values to models.json, which gets serialized into prompt context—causing credentials to leak directly into conversations during debugging sessions.

The ClawHavoc Campaign

Starting January 27, 2026, an actor named “Hightower6eu” uploaded 354 professionally-documented malicious packages with innocuous names like “solana-wallet-tracker.” These skills contained Windows keyloggers and macOS Atomic Stealer malware.

When malicious skills execute, they gain access to everything the agent can access:

  • Configuration files containing credentials
  • Environment variables
  • SSH keys and AWS credentials
  • Browser cookies
  • Filesystem contents

The attack exploits how OpenClaw skills work: natural language directives instruct agents to execute code, and agents follow instructions without distinguishing legitimate from malicious sources.

Why Current Mitigations Fall Short

OpenClaw has implemented several security measures:

  • SecretRef (environment variable indirection)
  • Auth profiles (system keychain storage)
  • Third-party integrations (1Password/Bitwarden via exec providers)
  • Security audit command (openclaw security audit --deep)

These mitigations operate at a surface level:

  • Credentials still load into process memory regardless of storage method
  • Config write operations can resolve environment variables back to plaintext
  • Keychain protection doesn’t prevent runtime access in multi-agent deployments
  • Audit commands detect leaks after they occur, not before

The fundamental issue: credentials exist within the agent’s runtime environment, making them accessible to any code the agent executes.

The Vault-First Alternative

A vault-first architecture removes credentials from the process entirely. Instead of storing API keys in the agent’s environment, agents hold references (vault tokens) to credentials stored in a secure vault.

This approach:

  1. Creates audit trails — Every credential access generates a logged API request
  2. Enforces scoped permissions — Agents access only authorized credentials
  3. Prevents bulk exfiltration — Attackers cannot crawl credential directories; each secret requires authenticated requests
  4. Simplifies rotation — Update underlying credentials once; all agents receive new values automatically

The Broader Pattern

This vulnerability mirrors the LiteLLM fork bomb incident: malicious packages harvest credentials because credentials live where code executes. The difference is scale—OpenClaw powers hundreds of thousands of agents connected to enterprise SaaS systems.

A 12% malware compromise rate in a major agent marketplace represents not a unique failure but an inevitable outcome when credential architecture treats secrets as runtime configuration values rather than restricted references.

Key Takeaway

Supply chain attacks against agent frameworks are inevitable. The question isn’t prevention but blast radius. When credentials live in the environment, attackers take everything. When credentials live in a vault, they take only audited, scoped, revocable references—transforming silent harvests into detectable security events.

AgentLair provides credential vault and identity infrastructure for AI agents. Learn more at agentlair.dev

Taking Morgan Willis’s 10-Minute Agent to the Next Level: Meet Alfred

I recently came across this fantastic post by @morganwilliscloud: “AI Agents don’t need complex workflows: Build one in Python in 10 minutes.” Her point was clear: we often overcomplicate Agentic AI. You don’t need massive enterprise frameworks to build something functional. Inspired by that “build-to-understand” philosophy, I decided to create Alfred—my personal digital butler running locally on my Linux Mint machine.
🧠 The Brains: Local & Private

Following Morgan’s lead, I skipped the heavy cloud APIs. Instead, I used Ollama with the Qwen 2.5 Coder (7B) model. It’s incredibly snappy at function calling and runs entirely on my hardware.
🛠️ Giving Alfred “Hands” (The Tools)

While a basic agent might just do math, I wanted Alfred to actually manage my OS. Using Python’s subprocess and psutil, I gave him four specific skills:

System Health Check: He monitors CPU, RAM, and Disk usage in real-time.

Multimedia Control: He scans my ~/Videos and ~/Music folders to launch VLC or Audacious on command.

Deep Search: A smart wrapper around the find command to locate any file across the system.

Content Discovery: Using grep to find specific strings inside text files without me having to remember complex flags.

💻 The Implementation

I used a lightweight orchestration layer to handle the loop, ensuring Alfred maintains his “impeccable British butler” persona while executing technical tasks.

The heart of the Butler

agente = Agent(
model=model,
tools=[media_play, system_status, fast_search, find_text],
system_prompt=(
“You are ALFRED, kernel’s digital butler. Your tone is impeccable and polite.n”
“RULES:n”
“- ALWAYS call a tool if the request is technical.n”
“- Be brief and address him as ‘Sir’ or ‘Juan’.”
)
)

🛡️ Security First

As Morgan emphasizes in her cloud architecture sessions, automation must be secure. Since Alfred has access to my shell, I implemented shlex for input sanitization:

Sanitizing user input for safe shell execution

safe_query = shlex.quote(query.strip())
cmd = f”find {USER_HOME} -iname ‘{query}‘ -type f 2>/dev/null | head -n 10″

🚀 Why This Matters

Building this taught me that the “10-minute agent” isn’t just a toy—it’s a foundation. Alfred now saves me several minutes a day by fetching files and checking system vitals through a simple chat interface.

A huge thanks to @morganwilliscloud for stripping away the complexity and showing that the best way to learn AI is to give it the keys to your terminal (carefully!).

Before Your Agent Pays, It Needs to Prove Who It Is

Cover

Cover

Most developers building AI payment flows focus on the transaction itself. Will the API call succeed? Will funds move? Will the webhook fire?

They skip a harder question: who is making that payment? Not the user. The agent.

The Identity Gap in Agentic Payments

When a human pays, identity is bundled into the flow. Card number, billing address, 3DS challenge the payment network has spent decades building systems to verify that a real person authorized a real transaction.

Agents break all of that. An AI agent calling a payment API is not a human. It does not have a billing address. It cannot complete a CAPTCHA. And if you hand it a raw API key, that key carries the full identity and authority of whoever owns it with no way to tell the agent apart from its operator.

This creates a scenario developers rarely think about until it goes wrong:

# Dangerous pattern -- agent gets full operator credentials
agent = MyAgent(api_key=os.environ["ROSUD_API_KEY"])
agent.run("Book the cheapest flight to Singapore")
# Agent now has the same payment authority as the operator
# No audit trail. No spending limit. No sub-agent boundary.

If that agent misbehaves misunderstands an instruction, gets prompt-injected, runs recursively it can spend without limit, and your logs will show a single API key doing everything.

What Agent Identity Actually Needs

Real agent identity requires three things:

  • Scope the agent can only spend within defined categories (flights, not payroll)
  • Limits a ceiling the agent cannot exceed, per transaction and per session
  • Auditability every payment traces back to which agent made it, not just which account owns it

This is different from human identity. You do not need a photo ID. You need a scoped credential that answers: what is this agent allowed to do, right now, in this context?

Scoped Credentials in Practice

Scoped credentials

Here is how Rosud handles this. Instead of sharing operator-level credentials with agents, you issue session-scoped tokens:

import rosud

session = rosud.sessions.create(
    agent_id="travel-booking-agent-v2",
    allowed_categories=["travel", "accommodation"],
    spending_limit_usd=500,
    ttl_seconds=3600,
    metadata={"task_id": "trip-sgp-2026-04"}
)
agent_token = session.token

# Payment uses scoped token -- succeeds within limit
rosud.pay(
    token=agent_token,
    amount_usd=320,
    category="travel",
    description="SIN flight booking"
)

# This fails -- exceeds spending_limit_usd: 500
rosud.pay(
    token=agent_token,
    amount_usd=600,
    category="travel",
    description="Business class upgrade"
)

The operator’s master credentials never leave the server. The agent gets a token that expires, has a spending ceiling, and logs every attempt against its own agent_id.

Why This Matters at Scale

A single agent hitting a payment rail once is a demo. A production system has dozens of agents sub-agents, parallel workers, scheduled tasks all potentially touching payments.

Without scoped identity, your audit log becomes unreadable. Every charge looks the same. When something goes wrong (and it will), you cannot tell which agent caused it, what task it was running, or whether it acted within its intended scope.

With scoped credentials, you get a ledger that traces payments to individual agent sessions. Cost attribution becomes automatic. Anomaly detection becomes possible. And when you need to revoke access, you revoke one session token, not your entire payment account.

The Right Abstraction

The payment industry built identity infrastructure for humans. Credit cards, 3DS, biometrics all designed for a person sitting at a browser.

Agents are not persons. They are processes, spawned at scale, running autonomously, often without a human in the loop.

The right abstraction for agent identity is not a user credential. It is a scoped, expiring, auditable token that encodes what the agent is allowed to do and nothing more.

That is the gap Rosud is built to close. Not just moving money, but moving it with verifiable agent identity attached.

If you are building autonomous payment flows, the question is not just “can my agent pay?” It is: can I prove, after the fact, that the right agent paid the right amount for the right reason? That proof starts with identity.

Rosud provides payment infrastructure for AI agents scoped credentials, spending limits, and audit trails built for autonomous systems. Learn more at rosud.com

7 Mac Apps That Make Developer Presentations and Live Demos Effortless in 2026

Whether you’re giving a conference talk, demoing a feature to stakeholders, or streaming a coding session — your Mac setup matters. A stray notification, a bad webcam angle, or fumbling through windows can kill the momentum of an otherwise great presentation.

Here are 7 Mac apps I rely on to make demos and presentations smooth, professional, and distraction-free.

1. Raycast — Launch Anything Instantly

Raycast is a launcher that replaces Spotlight and then some. During live demos, the last thing you want is to fumble around looking for an app or a file. Raycast lets you open anything with a few keystrokes, switch between windows, run scripts, and even trigger custom workflows. It’s the fastest way to look like you know exactly what you’re doing on stage.

Price: Free (Pro available)

2. CleanShot X — Screenshots and Screen Recording Done Right

CleanShot X is the best screenshot and screen recording tool on macOS, period. For presenters, the scrolling capture, annotation tools, and quick screen recording are invaluable. Need to grab a snippet of your terminal output mid-demo? CleanShot handles it without breaking your flow. The desktop overlay feature also hides your messy desktop automatically.

Price: $29 one-time

3. Hand Mirror — Quick Webcam Check Before Going Live

Hand Mirror lives in your menu bar and gives you a one-click webcam preview. Before jumping on a Zoom call, starting a stream, or walking up to the podium, you can check your camera angle, lighting, and whether there’s something stuck in your teeth. It’s a tiny app that prevents embarrassing moments.

Price: Free (Pro $4.99)

4. TokenBar — Keep an Eye on API Costs During AI Demos

TokenBar sits in your menu bar and tracks your LLM token usage in real time. If you’re demoing anything involving OpenAI, Claude, or other LLM APIs, having a live token counter visible is incredibly useful — both for you and your audience. I’ve used it during conference talks to show exactly how much an AI workflow costs per request. It makes abstract API pricing tangible.

Price: $5 lifetime

5. Monk Mode — Block Notifications and Feeds During Presentations

Monk Mode is a focus tool that blocks distracting feeds at the content level — not just the app level. Turn it on before a presentation and you won’t get ambushed by a Twitter timeline, YouTube recommendations, or Reddit threads if you need to open a browser during your demo. It also blocks notifications that could pop up at the worst possible moment. Nothing kills a live demo faster than a personal message appearing on the projector.

Price: $15 lifetime

6. KeyCastr — Show Your Keystrokes On Screen

KeyCastr displays your keystrokes as an overlay on screen, which is essential for coding demos and terminal walkthroughs. When your audience can see what you’re typing, they can follow along instead of wondering what shortcut you just used. It’s open source, lightweight, and you can customize the position and style of the overlay to match your presentation.

Price: Free (open source)

7. OBS Studio — Professional Streaming and Recording

OBS Studio is the gold standard for streaming and recording. Even if you’re not a streamer, OBS is incredibly useful for recording conference talks, setting up multi-scene demos, or compositing your webcam over your screen share. The scene switching feature lets you transition smoothly between your slides, your code editor, and your terminal without any awkward window juggling.

Price: Free (open source)

Bonus: The Presentation Stack

These seven apps cover different parts of the presentation workflow:

  • Prep: Hand Mirror (camera check), Monk Mode (distraction blocking)
  • During: Raycast (fast switching), KeyCastr (keystroke visibility), TokenBar (API cost tracking)
  • Capture: CleanShot X (screenshots/recordings), OBS Studio (full recording/streaming)

The best part is that most of these are set-and-forget — configure them once, and they just work in the background every time you present.

If you give talks, demos, or streams regularly, having a solid toolchain makes the difference between looking polished and looking like you’re fighting your own machine. These are the apps that keep my presentations running smoothly in 2026.

What’s in your presentation toolkit? Drop your picks in the comments 👇

We Scanned 4,275 MCP Servers. Most of Them Shouldn’t Be Trusted.

The Model Context Protocol is the connective tissue of the AI agent ecosystem. It’s how Claude, Cursor, VS Code Copilot, and hundreds of other AI tools connect to external services, databases, APIs, and local system resources. There are now over 16,000 MCP servers in the wild, and the number is growing by hundreds every week.

We’ve spent the last several months scanning, analyzing, and probing MCP servers at scale. Our registry at CraftedTrust has indexed 4,275 servers and scored each one across 12 security categories aligned to the CoSAI threat taxonomy. What we found is concerning.

The average trust score for statically analyzed npm packages is 54 out of 100. That’s an F.

The problem is structural, not incidental

MCP servers occupy a uniquely dangerous position in the software stack. A traditional API serves data to an application that a developer controls. An MCP server serves data and capabilities to an AI model that reasons about what to do next. The model decides which tools to call, what parameters to pass, and how to interpret results. This means a compromised or poorly built MCP server doesn’t just return bad data. It can influence the behavior of the entire agent.

Three categories of vulnerabilities show up repeatedly across the ecosystem.

1. Servers that give agents too much power with too few guardrails

This is the most common pattern. An MCP server exposes a tool that does something dangerous (execute code, navigate a browser, run shell commands, read the filesystem) and relies entirely on the AI model to use it responsibly.

We recently published a critical advisory for chrome-local-mcp, an npm package with 332 weekly downloads that gives AI agents browser automation capabilities. We found three chained vulnerabilities:

Arbitrary JavaScript Execution (CWE-94, Critical): The server exposes an eval MCP tool and an HTTP /eval endpoint that pass user-supplied JavaScript directly to Puppeteer’s page.evaluate() with no restrictions whatsoever. Because the browser uses a persistent profile directory that retains login sessions across invocations, an attacker can navigate to any site where the user is logged in and extract document.cookie, localStorage, session tokens, or any DOM content.

SSRF via Unrestricted URL Navigation (CWE-918, High): The navigate tool passes URLs directly to page.goto() with no validation. No scheme allowlist (accepts file://, data:, javascript:), no hostname blocklist (allows 169.254.169.254, localhost, internal IPs), and no port restriction. On cloud-hosted deployments, this enables direct credential theft from instance metadata endpoints.

Unauthenticated HTTP API on All Interfaces (CWE-306, High): The Express server listens on 0.0.0.0 with no authentication. All 15 endpoints are accessible to any local process or network neighbor. Any website opened in a regular browser can send fetch('http://localhost:3033/eval', {method:'POST', body:...}) to execute arbitrary JavaScript in the Puppeteer session.

These three findings chain together into a full attack: any website you visit in your normal browser can silently call the unauthenticated local API, navigate the Puppeteer session to a site where you’re logged in, and extract your credentials. No user interaction required beyond having the MCP server running.

The full advisories are published on CraftedTrust Touchstone.

2. Supply chain trust is nearly nonexistent

MCP servers are typically installed via npx from npm or cloned from GitHub. The installation process is: a user copies a JSON config snippet from a README, pastes it into their MCP client config, and the next time their AI tool starts up, it runs npx some-package as a subprocess with whatever permissions the user has.

There is no code signing. There is no permission manifest. There is no sandbox by default. If the package author pushes a malicious update, it executes automatically the next time the user’s AI tool starts.

We published two supply chain advisories this week. One for a third-party republication of the official Notion MCP server (@osematouati/notion-mcp-server) that claims to be “Official” and points its repository field to Notion’s GitHub org but has no npm provenance attestation and a single maintainer. Another for a Gmail MCP server (@gongrzhe/server-gmail-autoauth-mcp) requesting gmail.modify and gmail.settings.basic scopes with zero provenance verification across all 7 published versions.

Research from other teams corroborates the scale: Astrix Security found that 53% of MCP servers use static secrets (API keys embedded in configuration), BlueRock Security found 36.7% of 7,000+ servers potentially vulnerable to SSRF, and the OpenClaw ecosystem saw over 800 malicious skills published across 12 attacker accounts, roughly 20% of the ClawHub registry.

3. The attack surface extends beyond tool descriptions

CyberArk’s research demonstrated that tool poisoning doesn’t just hide in the description field. Every schema field is a potential injection vector: parameter names, types, anyOf/oneOf constructs, enum values, and even tool output. Their testing showed an 84.2% success rate for tool poisoning attacks with auto-approval enabled. Invariant Labs found that even the best-performing model (Claude 3.7 Sonnet) had less than a 3% refusal rate against tool poisoning, and more capable models are actually more susceptible.

This means traditional security scanning that only checks for known malicious patterns in tool descriptions is catching a fraction of the real attack surface.

What we’re doing about it

CraftedTrust operates as an independent trust verification layer for the MCP ecosystem. Every server in our registry is scored across 12 security categories: identity and authentication, permission scope, transport security, declaration accuracy, tool integrity, supply chain, input validation, data protection, network behavior, code transparency, publisher trust, and protocol compliance. Scores map to five compliance frameworks (CoSAI, OWASP Top 10 for Agentic Apps, EU AI Act, NIST AI RMF, and AIUC-1).

Our security research arm, CraftedTrust Touchstone, runs automated deep scans across 60 security checks in 8 domains, auto-triages findings, and manages a 90-day coordinated disclosure pipeline. When we find something, we notify the maintainer, give them 90 days to fix it, and publish the advisory with full technical details.

We also built an MCP server interface so AI agents can check trust scores programmatically before connecting to any server. Add CraftedTrust to your agent’s MCP config and it can call check_trust on any server URL before deciding whether to connect:

{
  "mcpServers": {
    "craftedtrust": {
      "url": "https://mcp.craftedtrust.com/api/v1/mcp"
    }
  }
}

Six tools are available: check_trust, scan_server, search_registry, get_stats, pay_for_certification, and verify_payment. The search and stats tools are free. Premium endpoints accept x402 micropayments (USDC on Base) so agents can pay per-request without API keys or subscriptions.

What you should do right now

If you’re using MCP servers with your AI tools:

Audit what’s installed. Check your Claude Desktop, Cursor, or VS Code MCP config files. Every server listed there runs with your user permissions. If you don’t recognize it or don’t actively use it, remove it.

Check trust scores. Search for your installed servers at mcp.craftedtrust.com. If a server scores below 40 (grade D or F), investigate before continuing to use it.

Prefer servers from verified publishers. Look for servers published by the organization they claim to represent (e.g., @notionhq/notion-mcp-server over third-party republications), with multiple maintainers, npm provenance attestation, and active GitHub repositories.

Don’t auto-approve tool calls. Most MCP clients support an approval flow for tool calls. Use it, at least for servers that have filesystem, network, or code execution capabilities.

If you’re building MCP servers:

Get scanned. Submit your server URL at mcp.craftedtrust.com for a free 12-category trust assessment. If you want a deeper review, our certification tiers ($29/$79/$499) include enhanced scanning, compliance framework mappings, and a verified trust badge.

Read the OWASP MCP Top 10. It covers the attack patterns we see most frequently: tool poisoning, excessive permissions, SSRF, credential exposure, and supply chain compromise.

Add authentication. If your server exposes any capability beyond read-only public data, it should require authentication. OAuth 2.1 with PKCE is the standard. At minimum, don’t bind to 0.0.0.0 without auth.

The MCP ecosystem is growing fast and building incredible capabilities. But the security posture of most servers assumes a world where every AI model always does exactly what the developer intended. That world doesn’t exist. The sooner we build trust verification into the agent connection flow, the safer this ecosystem becomes for everyone.

Jeremy Kenitz is the founder of Cyber Craft Solutions LLC and the creator of the CraftedTrust Agent Trust Stack. CraftedTrust Touchstone advisories are published at touchstone.craftedtrust.com.