Ido Green

I recently joined the MSP 1337 podcast with Chris Johnson to talk about something I’ve been thinking about for years:

Small and midsize businesses are being asked to operate with enterprise-level security expectations — without enterprise-level resources.

That gap is becoming impossible to ignore.
And AI is accelerating both sides of the problem.

Attackers are moving faster.
Infrastructure is becoming noisier.
Compliance requirements are multiplying.
Meanwhile, SMBs and MSPs are still expected to somehow manage everything with limited staff, fragmented tools, and endless alerts.

That model is cracking.

Btw, you can listen to it here:
– Apple Podcasts
– Spotify

The Problem Isn’t Lack of Security Tools

The cybersecurity market is overflowing with products.

Another RMM.
Another EDR.
Another dashboard.
Another SIEM.
Another “AI-powered” feature.

But most SMBs don’t actually suffer from a lack of tooling.

They suffer from:

• Too many disconnected systems
• Massive operational overhead
• Alert fatigue
• Compliance drift
• Lack of skilled security personnel
• No realistic way to continuously enforce policy

And this is where most security conversations become disconnected from reality.

Enterprise security models assume: dedicated SOC teams, compliance departments, security engineers, analysts tuning detections and people reviewing thousands of events.

Most SMBs have none of that.
Sometimes the “security team” is: The MSP, the office manager or the founder wearing five hats.
Not so good.

The False Positive Problem Is Still Killing Everyone

One of the biggest issues in cybersecurity is not detection.

It’s prioritization.

Every platform can generate alerts.
Every system can scream.

The real challenge is figuring out: Which signals actually matter?

Anyone who has worked with SIEMs, firewall logs, endpoint alerts, or compliance tooling knows the pattern:
you turn something on and suddenly drown in noise.
And SMBs don’t have months available for “tuning.”
They need operational clarity immediately.

That’s one of the core reasons we built Espresso Labs the way we did.

• Not to replace humans.
• Not to pretend AI is magic.
• But to eliminate huge amounts of repetitive operational work.

If AI can safely handle: Level 1 triage, repetitive remediation, evidence gathering, inventory correlation, policy enforcement, baseline monitoring, then human operators can focus on the things that actually require judgment.
That’s the shift.

AI Without Guardrails Is Dangerous

There’s a lot of excitement around AI agents right now.
There should be.

But there’s also a dangerous amount of blind trust entering the industry.

Security is not the place for vague prompts and “hopefully it works.”
You absolutely do not want:

• an agent touching sensitive systems without boundaries,
• unrestricted access to production environments,
• or AI improvising security decisions.

That’s why we designed our local agents and browser controls around strict guardrails and isolation.

AI should augment operational capability.
Not create a new attack surface.
The right model is:

• constrained execution,
• scoped permissions,
• auditable actions,
• human escalation paths,
• and continuous supervision.

Especially in cybersecurity.

SMBs Need Enterprise Capabilities — Without Enterprise Complexity

One realization became obvious very early for us:
SMBs still need:

• endpoint security
• compliance enforcement
• browser protection
• backup validation
• inventory visibility
• policy management
• user monitoring
• ticketing
• audit trails
• drift detection
• remediation workflows

They just can’t afford a giant security team to operate all of it.
So the question became:
Can AI reduce the operational cost of security enough to make strong security realistic for smaller organizations?

That’s the problem we’re solving.

Compliance Is Becoming Continuous — Not Annual

This is especially visible with:

• Cybersecurity Maturity Model Certification (CMMC)
• SOC 2
• ISO 27001
• cyber insurance requirements
• vendor security assessments

Historically, compliance was treated like a snapshot: prepare, audit, pass and move on.

But modern environments drift constantly.

New users appear.
Devices change.
Policies weaken.
Software becomes vulnerable.
People leave companies.

The environment changes daily.
So the future of compliance is not “annual preparation.”
It’s continuous enforcement.

That means:

• detecting drift automatically,
• continuously validating controls,
• proving remediation,
• maintaining evidence in real time.

This is where AI becomes incredibly powerful.

Instead of generating a PDF telling you what’s wrong…
the system can: identify the issue, explain the impact, enforce the control, validate the result and document the evidence.
That changes the economics of compliance entirely.

MSPs Need Flexibility — Not Another Locked Ecosystem

One thing I strongly believe:

MSPs should not be forced into a “take it or leave it” platform.

If you already use:

• CrowdStrike
• SentinelOne
• Bitdefender
• Fortinet

you shouldn’t have to rip everything out.

The real value comes from correlation and orchestration.
Security tools become exponentially more useful when: logs are centralized, inventory is unified, policies are enforceable and remediation becomes automated.

The goal is operational leverage — not forcing replacement.

The Bigger Shift Is Operational AI

Most people still think about AI in cybersecurity as: chatbots, copilots, summaries or search.

But the bigger opportunity is operational execution.
AI that can:

• monitor continuously
• learn organizational baselines
• suppress known-good noise
• escalate intelligently
• automate low-risk remediation
• maintain compliance posture.

That’s where this is all heading. Not AI replacing humans.
AI removing operational drag.

Cybersecurity Is Becoming a Scale Problem

The reality is simple:
Attackers are scaling with AI.

Defenders need to scale too.

But SMBs cannot solve this by hiring massive teams.
The economics don’t work.

The only viable future is:

• better automation,
• safer AI execution,
• continuous enforcement,
• and drastically reduced operational overhead.

That’s the direction we’re building toward at Espresso Labs.

And honestly, I think the entire industry is heading there whether it realizes it yet or not.

Recommended Reading

During the podcast, I mentioned one book I keep returning to:

The Psychology of Money by Morgan Housel
Not a cybersecurity book — but one of the best books on long-term thinking, incentives, and human behavior.
A lot of it applies surprisingly well to security leadership too.
You can learn more about Espresso Labs at: Espresso Labs

Be strong

Last week I was staring at my EnduraCoach dashboard, watching it yell at me for sneaking in an extra sprint session that my body wasn’t ready for. The AI caught the overtraining pattern across heart-rate, sleep, and power data and shut it down before I wrecked my Ironman build. That same evening the April ransomware numbers landed. SMBs got hammered again. And I thought: if only every founder had an always-on coach like this for their security stack.

Here’s the uncomfortable truth from April 2026: ransomware didn’t slow down—it accelerated. A new player called JanaWare quietly encrypted files for hundreds of Turkish home users and small businesses through targeted phishing campaigns. Low-dollar demands ($200–$400) but high volume. Attackers are learning that SMBs are softer targets and faster payers.

The broader picture is uglier.
Verizon’s 2025 DBIR (still the gold standard) showed 88% of ransomware breaches hit SMBs versus just 39% for enterprises. Unpatched vulnerabilities caused 29% of incidents; stolen credentials another 30%.
Sophos and Black Kite reports confirm SMBs in the $4M–$8M revenue band are now the sweet spot for attackers.

Most of us simply don’t have a 24/7 SOC or the headcount to patch, triage, and remediate at machine speed.

Why your current stack is losing the race

You already know the drill—I wrote about it two weeks ago. You’ve got EDR, a SIEM that spits 800 alerts a day, cloud config tools, backup solutions, and a compliance spreadsheet that lives in Google Docs. Your one-person IT “team” (probably you or your CTO wearing three hats) can’t keep up. Alerts become noise. Drift happens. A single phishing email or unpatched server becomes a full-blown encryption party.

Meanwhile, attackers have upgraded. Remember my Claude Mythos experiment in April? One air-gapped model autonomously built an exploit chain and phoned home. Offensive AI agents are now table stakes for ransomware groups. Defensive point tools can’t match that speed.

The fix we’re actually shipping at Espresso Labs

This is exactly why we built Espresso Labs: one unified AI-powered platform that replaces the dozen disconnected tools and the missing SOC. At the center is Barista—our continuous AI agent that doesn’t just alert. It acts.

Barista watches endpoints, cloud configs, identities, and backups 24/7. It triages, quarantines, remediates, and collects audit-ready evidence in real time. Human experts back it up when needed. For CMMC, SOC 2, or HIPAA it enforces controls continuously instead of chasing checkboxes. Founders tell us it cuts compliance cost and timeline by up to 80% while actually stopping breaches.

Think of it as EnduraCoach for your entire tech stack: always connected, always enforcing the plan, and stepping in before you even notice the problem.

Two real-world SMBs that would still be running if they had Barista

Example 1: A Dental Clinic (12 employees, California)
Late April 2026 the practice got hit via the fresh cPanel vulnerability (CVE-2026-41940). One unpatched server, no continuous scanning, and “Sorry” ransomware encrypted patient records and scheduling systems in under 40 minutes.
Downtime cost them $18k in lost appointments plus a $45k ransom negotiation.
They paid.
Data was partially recovered.

With Espresso Labs this never happens.
Barista’s agents would have auto-detected the cPanel drift during its nightly vuln sweep, patched it automatically, and isolated the server the moment anomalous encryption behavior started.
Immutable backups would have let them restore in minutes with zero ransom paid. The clinic keeps seeing patients instead of calling their MSP in panic.

Example 2: A Marketing Agency (8 employees, remote-first)
A senior designer clicked a sophisticated phishing link dressed as a client creative brief.
Stolen credentials gave attackers initial access. Within hours they deployed ransomware across the shared drive and exfiltrated client campaigns. The agency lost three days of billable work and faced a $32k demand.
Classic stolen-credential playbook—exactly the 30% bucket from the Verizon report.

Barista would have caught and blocked the malware download, and rolled back from the last clean backup automatically. The designer gets a gentle “hey, that link looked sketchy—let’s run a quick training module.” No encryption, no exfil, no headlines.

These aren’t hypotheticals.
These patterns played out in April for dozens of SMBs just like yours.

Your 5-step practitioner playbook (do this this week)

1. Stop buying another tool. Audit what you actually have running and where data lives. Most SMBs discover they’re paying for 70% overlap.
2. Demand continuous enforcement. Point-in-time scans are dead. You need agents that watch 24/7 and fix drift instantly.
3. Test autonomous remediation on one workload. Spin up a low-risk environment (dev server, staging) and let an agent like Barista practice quarantining and restoring.
4. Layer in phishing simulation + training that actually sticks. Barista does this natively and measures real behavior change.
5. Get your compliance evidence automated. If you’re chasing CMMC Level 2 or SOC 2 Type 2 this year, manual evidence collection is the fastest way to fail an audit.

Your startup isn’t a marathon—it’s brutal sprints.
Security in 2026 is the same.
One missed sprint and the whole race ends. Continuous AI agents turn defense into a sprint you can actually win.

The tech exists today. We’re running it for our own early customers and it feels exactly like the relief EnduraCoach gives me mid-training: someone (or something) smarter has your back.

If your April numbers looked anything like the industry’s, drop a comment: what’s your biggest security headache right now?
Or head to espressolabs.com and book a 15-minute Barista demo.
No slide deck, no hard sell—just a live look at what continuous actually feels like.

Stay safe out there.
Train hard, ship secure, and let the AI do the heavy lifting.

There’s a lot of confusion right now between MCP (Model Context Protocol) and “Agent Skills.” They’re often mentioned in the same breath, but they solve different problems. If you treat them as interchangeable, you’ll either over-engineer simple workflows or underpower serious integrations.

Here’s the clean way to think about it.

The Core Difference

MCP is about connecting agents to systems.
Skills are about teaching agents how to do things.

That distinction alone gets you 80% of the way.

Integration Model

MCP is a client-server protocol. You stand up an MCP server, expose tools, and now multiple agents can talk to multiple backends through a consistent interface. It’s a hub.

Skills are much simpler: a folder with a SKILL.md file. The agent loads it when triggered and follows the instructions. No protocol, no network layer, no abstraction.

Implication:

• MCP scales across teams and services
• Skills scale across use cases and workflows

Architecture

MCP runs as a separate process with its own runtime, typically speaking JSON-RPC. It’s a real service—versioned, deployed, monitored.
The MCP mindset: “How do I give my agent access to the documents, tools, and databases it needs to see what’s happening?”

MCP is your Integration Layer:

1. Universal Connectivity: An agent built with MCP support can instantly connect to any MCP-compliant server. If a new vector database, a CRM, or a local file parser releases an MCP server, your agent can integrate it without you writing a single line of new integration code.
2. Context-Aware Data Access: MCP isn’t just about calling functions; it’s about providing the agent with the context it needs. The protocol allows the agent to query local repositories, read files, and browse databases securely. This transforms the agent from a static model into a system aware of its environment.
3. Security and Control: The MCP host application (the part running the agent) maintains control. It decides which servers are available, which prompts are permitted, and which tools can be executed. This is critical for building “serious” systems where you cannot simply give an LLM unfettered access to your entire network.

A Skill is just a directory:

• SKILL.md (the brain)
• optional scripts (bash, Python, etc.)
• references or assets

No runtime. No server. Just files.

Implication:

• MCP introduces infrastructure (and overhead)
• Skills stay lightweight and local

Invocation Model

With MCP, tools are explicitly called:

• typed parameters
• validated schemas
• predictable outputs
• chainable across services

This is structured, deterministic, and machine-friendly.

Skills are implicitly invoked:

• the agent reads SKILL.md
• interprets instructions
• runs commands (bash, Python, curl, etc.)

This is flexible, but less controlled.

Implication:

• MCP is better for reliability and composition
• Skills are better for adaptability and speed

Runtime

MCP servers typically run in their own container or service. They’re isolated, scalable, and can be shared.

Skills run inside the agent’s environment. No extra infra. If the agent can execute it, it works.

Implication:

• MCP is an ops problem
• Skills are a local capability

---

Where Each Fits

Use MCP when:

• You need to connect to live systems (databases, APIs, SaaS tools)
• You want multiple agents using the same tools
• You care about typed interfaces and reliability
• You’re building something closer to a platform

Use Skills when:

• You want reusable know-how
• You’re encoding workflows, playbooks, or heuristics
• You need fast iteration without infra
• The task is more about how to think/do, not how to connect

The Practical Take

If you’re building serious agent systems, you’ll end up using both.

• MCP becomes your integration layer
• Skills become your behavior layer

One connects the agent to the world.
The other teaches it what to do once it gets there.

Trying to replace one with the other is where things break:

• Using Skills to call complex APIs → messy, fragile
• Using MCP for simple workflows → overkill

A Simple Mental Model

• MCP = “I need access to this system”
• Skill = “I need to know how to do this task”

Keep that boundary clean, and your architecture stays sane.

Andrew Ross Sorkin’s book “1929: Inside the Greatest Crash in Wall Street History—and How It Shattered a Nation” (published in 2025) provides a forensic, narrative-driven account of the most famous market collapse in history.
Sorkin, who also wrote the 2008 crisis definitive history Too Big to Fail, focuses on the human psychology, hubris, and technical failures that turned a speculative boom into a generational disaster.

Here are the top 20 takeaways from the book, followed by specific lessons for you as a long-term investor.

1. Euphoria is the market’s most dangerous condition
Pessimism had gone out of fashion by the 1920s. Government commissions, governors, and economists all declared boom-and-bust cycles relics of a vanished age — it was a fatal illusion. When everyone agrees the good times will last forever, that’s when risk is highest.

2. “This time is different” is always the most expensive phrase in investing
The dangers of “this time is different” thinking are as present in the crypto, AI, and tech booms of 2025 as they were in 1929. Every bubble in history has come with a new rationalization for why old rules no longer apply.

3. Long booms destroy your ability to assess risk
Sorkin writes that “lengthy, uninterrupted booms produce a collective delusion… people lose their ability to calculate risk and distinguish between good ideas and bad ones.” The longer the bull run, the more dangerous your own judgment becomes.

4. Easy credit and leverage are the true accelerants of a crash
Margin loans had grown from $1 billion in 1920 to $6 billion by 1929. Borrowed money turns a correction into a catastrophe — for both individuals and the system.

5. Financial innovation can mask fragility
Financial innovation — then in the form of investment trusts, now echoed in SPACs and cryptocurrencies — created an illusion of invincibility while hiding fragility. New instruments rarely eliminate risk; they often just disguise it.

6. Smart money exits quietly while retail money piles in
Charles Merrill “had been telling clients to get out of the stock market since March of 1928.” The New York Times observed in March 1929 that “the people who know least about the stock market have made the most money out of it in the last few months” — signaling the smart money had already sold.

7. Manipulation and conflicts of interest are a constant, not an aberration
Wealthy investors would pool their assets to purchase stock in a target company, inflate the price through internal trades, leak bullish information to the press, and then dump shares at peak prices. This behavior was unethical, but not illegal. Assume that not all market activity is what it appears.

8. Regulatory dawdling turns problems into catastrophes
Sorkin highlights the role of regulatory dawdling — alarm bells were ignored and financial innovation was left unchecked until it was too late. Policy always lags markets, and long-term investors must price that in.

9. Even the most sophisticated investors are not immune
Groucho Marx and Winston Churchill both took a bath when the crash came. Wealth, intelligence, and connections offer no protection when the tide turns.

10. Humility is the most underrated investment strategy
Sorkin closes with: “The enduring lesson is that we need to remember how easily we forget. The antidote to irrational exuberance is not regulation by itself, nor skepticism, but humility — the humility to know that no system is foolproof, no market fully rational, and no generation exempt. The greater the heights of our certainty, the longer and harder we fall.”

11. Diversification and cash are lifelines, not weaknesses
Thomas Lamont quipped that “In my spare moments, I keep feeling cash is a good asset.” Maintaining liquidity and broad diversification protects you when the unexpected hits.

12. Markets can stay irrational far longer than you expect — then correct violently
By the end of trading on Black Thursday, 13 million shares had been dumped as spooked investors rushed for the exits. Then another $14 billion was lost on Black Tuesday, October 29. Long periods of stability breed complacency, making the eventual correction more severe.

13. Contrarian voices are often silenced — but worth heeding
Jesse Livermore stated publicly that the market was overpriced and stocks were at “ridiculously high prices.” By the end of October 1929, he had made $100 million on the short side of the market. The lonely, uncomfortable opinion is often the most important one.

14. Wealth inequality weakens the foundation of a bull market
Critics noted that Sorkin’s thesis — that the bifurcation of society into rich and poor was causal to the crash — points to how a narrow ownership of assets creates a fragile, top-heavy system.

15. Panic responses can make things worse — policy timing matters
The right response at the wrong time can be worse than no response at all. Reacting emotionally during a crash — whether as a government or as an individual investor — often destroys value rather than protecting it.

16. Deposit insurance and banking reform are the investor’s silent protectors
Sorkin lionizes the insistence on deposit insurance, noting that when it became law, “small-town America finally felt like it had won a battle with Wall Street.” The regulatory frameworks born of 1929 are the guardrails protecting your capital today — don’t take them for granted.

17. Character and incentives determine behavior under stress
Sorkin tells this story through the eyes of the powerful men — bankers, politicians, and speculators — whose decisions led the nation to the brink, and details their fatal miscalculations. Understanding who controls institutions, and what motivates them, is essential due diligence.

18. The market crash wasn’t recognized for what it was — in real time
The New York Times didn’t even select the stock market crash as the most important news story of 1929 — Richard Byrd’s round-trip flight to the South Pole was granted that honor. Major inflection points are rarely obvious until long after they happen.

19. History rhymes — the patterns repeat across generations
Sorkin draws lines from the roaring ’20s to the tech-driven and AI-fueled rallies of the current era, arguing that the remarkable parallels between that era and today’s political and economic climate are impossible to ignore.

20. Progress is fragile — even long, genuine booms can end badly
Sorkin’s book is “a timeless reminder that progress is fragile, choices have repercussions, and the flaws embedded in the human condition are ours to confront.” The best long-term investors don’t just ride trends — they build portfolios that can survive when those trends reverse.

---

The one-sentence takeaway for a long-term investor

The crash of 1929 was not caused by bad luck — it was caused by decades of leverage, delusion, and the human refusal to believe the party could end. Stay humble, stay diversified, and never let a long bull market convince you that risk has disappeared.

Every morning starts the same way: open Techmeme, scan headlines, open too many tabs, and somehow end up 20 minutes deep into something you didn’t mean to read.

That loop is the problem. Instead of trying to “summarize the internet” or build another bloated AI dashboard, this project does something much simpler: take a strong source, rank and summarize it, and deliver a clean digest to Slack or Telegram.

That’s it—and that’s why it works.

At a high level, the flow is straightforward: scrape Techmeme, extract headlines, use Gemini to rank and summarize, and send the result to Slack or Telegram. No overengineering, no fake architecture—just HTTP requests, parsing, prompting, and delivery.
The core logic sitting in index.js is exactly the right level of ambition. Small tools should stay honest.

Where this project stands out is in the details most people ignore. It validates configuration early, so if Gemini or Slack or Telegram isn’t set up correctly, it fails fast instead of wasting your time. It supports Telegram-only mode, which signals real-world usage. And it includes a simple telegram-test.js script so you can test delivery without running the full pipeline.
That’s the difference between a demo and something you actually rely on.

The hardest part here isn’t scraping or AI—it’s message delivery. Slack and Telegram look similar until you try to share formatting between them. This project handles that well: converting formatting, preserving links, escaping HTML, and—critically—splitting messages to stay under Telegram’s 4096-character limit. Even better, it splits intelligently (paragraphs → lines → words), so the output stays readable instead of turning into garbage. That’s a detail you only get right if you’ve actually used the tool.

The scraping approach is pragmatic.
It uses Cheerio with a primary selector and a fallback if the structure changes. It’s not bulletproof, but it’s not naive either. The code assumes the web will break—and plans for it.

The AI layer is useful, but slightly overreaches.
The prompt asks Gemini to cross-check sources like Reddit, X, and major outlets—but the pipeline only feeds it Techmeme. So it’s not true multi-source validation; it’s more like AI-assisted ranking with implied context.
That’s fine, but it’s worth being explicit about.
If you were to evolve this, you’d either add real secondary sources or tighten the prompt to reflect reality.

There’s also solid product judgment here. This bot isn’t trying to become a platform, dashboard, or “AI agent system.” It does one job: turn noisy headlines into a clean digest.
The README reflects that mindset—clear setup, practical guidance, and even help around Telegram chat IDs, which is exactly the kind of friction that kills tools like this.

A few things to watch: the scraper will need maintenance over time, the Gemini model config should be consistent across files, and a couple of focused tests (especially around parsing and message chunking) would make this much more robust.

Even with those gaps, this is a small/smart project.
It solves a real problem, keeps scope tight, and handles the unglamorous parts—validation, formatting, delivery—that actually determine whether something gets used.

The broader lesson is simple: most valuable AI tools right now aren’t massive systems.
They’re small, focused, and reliable.
One job, done well, delivered where you already work.

This bot fits that model.
And honestly, that’s where the value is.

At some point, every dev hits it.
You’re installing something routine—npm install, a Go build, whatever—and macOS throws it in your face:

Disk Full.

You check storage, expecting the usual suspects. Not your videos. Not even Docker (okay, maybe a little).
It’s Homebrew quietly eating your SSD in the background.

Left unchecked, Homebrew turns into a museum of bad decisions:

• tools you needed once, 14 months ago
• duplicate runtimes “just in case”
• dependencies of dependencies of dependencies

Let’s fix it—without nuking your setup.

Phase 1: Basic Hygiene

Start simple.
Most of the mess comes from neglect, not complexity.
Do This More Than Once a Year:

brew update && brew upgrade

Now the important one:

brew autoremove

This cleans up dependencies that are no longer needed. Think: uninstalling an app but leaving behind all its junk—this gets rid of the junk.

Then:

brew cleanup

By default, Homebrew keeps old versions around for 120 days. That’s generous to a fault. If you’re low on space:

brew cleanup --prune=all

That’s the “stop hoarding” flag.

Phase 2: Kill the Cache

Homebrew caches everything it downloads. Useful in theory. Useless in practice.

Check how bad it is:

du -sh $(brew --cache)

If you see gigabytes, don’t overthink it:

rm -rf "$(brew --cache)"

Nothing breaks. Worst case, Homebrew downloads stuff again later. Best case, you just freed multiple GB instantly.

Phase 3: Audit What You Actually Installed

Now for the uncomfortable part.

brew leaves

This shows only the packages you explicitly installed—not the dependency noise.

Scroll through it slowly. You’ll find:

• tools you forgot existed
• experiments you never cleaned up
• “productivity boosters” you never opened twice

If you don’t recognize it, remove it:

brew uninstall <package>

Be honest here. This is where most of the real cleanup happens.

Phase 4: Let Homebrew Diagnose You

When things feel off—broken builds, weird paths, random failures:

brew doctor

It’s surprisingly blunt. It will call out:

• permission issues
• broken symlinks
• outdated or conflicting installs

Fix what it tells you. It’s usually right.

The “Controlled Burn” Reset (When Things Are Truly Messy)

If your setup feels fragile or inconsistent, don’t keep patching it. Reset it cleanly.

First, snapshot what you actually want:

brew bundle dump --force

This creates a Brewfile—your source of truth.

Then clean everything not in that file:

brew bundle clean --force

This is the closest thing to a fresh start without losing your essentials.

One Command to Rule Them All

If you want to stay out of trouble, automate the basics:

alias brew-burn='brew update && brew upgrade && brew autoremove && brew cleanup && brew doctor'

Run it every couple of weeks. Takes a minute, saves hours later.

The Reality

You’re not running out of disk because macOS is inefficient.

You’re running out because:

• you install fast
• you delete slow
• and Homebrew never forgets

Clean it up once, and you’ll usually get back several gigabytes.
Ignore it, and you’ll be back here in three months wondering why your laptop feels like 2015 again.

Your call.

A few months ago, I finished a long ride—just over 100 miles, solid climbing, felt strong the entire way. The kind of session that makes you think, I’m on track.

The next week, I pushed again. Then again.

Nothing dramatic—just a bit more volume, a bit more intensity. Exactly what most self-coached athletes do when things feel good.

Two weeks later, I was flat. Not injured. Not sick. Just… off. Power was down, runs felt heavy, motivation dipped. The frustrating kind of fatigue where nothing is clearly wrong—but nothing is clearly right either.

When I looked back, the pattern was obvious:

• I had increased load too quickly
• Skipped a proper recovery week
• Let “feeling good” override structure

What’s worse: all the data was there.
Garmin had it.
The workouts were logged.
The signals existed.

I just didn’t have a system that could connect the dots, enforce discipline, and still adapt intelligently.

That’s the gap.

Most tools today fall into two extremes:

• Static plans that ignore what you actually did
• “AI coaching” that sounds smart but you can’t really trust

I wanted something in between:

A system that keeps me honest on the fundamentals—while still helping me think, adapt, and improve.

That’s where EnduraCoach started.

The bet: coaching that feels intelligent—without gambling on math.

EnduraCoach is an AI-assisted Ironman training app built on a simple premise:
the model does not control your training plan.

Instead, the system splits responsibilities:

• A deterministic engine owns load, progression, and structure
• The LLM handles conversation, explanation, and suggestions
• The user explicitly approves any changes

That separation isn’t academic—it’s the difference between something that sounds smart and something you can actually trust with your body.

Why not let the model run everything?

Because LLMs are excellent at language and context—and unreliable (or just less reliable) at consistent, safe, structured planning. In the (near) future, that might change and we can ‘give it all’ to the LLMs. But for now, let’s keep this part out of it.

Training plans require:

• Repeatability: same inputs → same outputs
• Bounded risk: no surprise spikes in load. We don’t want to get injured.
• Testability: you can verify behavior before doing a session.

So there’s a hard rule in the system:

The LLM never owns training math.

That constraint drives everything else.

The Core System

Think of EnduraCoach as three cooperating layers:

1. Deterministic Training Engine (the source of truth)

This is where the real coaching logic lives.

• Structured phases: base → build → peak → taper
• Recovery every 4th week
• Guardrails:
  • Intensity step <= +1 zone for beginner/intermediate, +2 for advanced
  • Weekly volume increase <= 15% for advanced cyclists, 12% intermediate, 10% beginner; 8% for all swim and run sessions
  • Mandatory recovery week every 4 weeks
  • Preset distributions by race distance
  • Monday-aligned week grid (so UI and logic never drift)

This is intentionally conservative.
You can reason about it.
You can test it – You can trust it.

2. Conversational Layer – LLM as advisor, not authority

The coach experience is powered by Google Gemini via @google/genai.

But it operates under strict constraints:

• No full chat history dumping
• A single structured memory state per user
• Fixed prompt structure:
• athlete profile
• goal
• current phase
• last week summary
• current week snapshot
• user message

This keeps responses:

• consistent
• grounded
• cheap (token-wise)
• actually useful

The model proposes ideas—it does not execute them.

3. Governance Loop: propose → approve → apply

This is the most important product decision.

When the model suggests a change:

1. It generates a proposal
2. The backend converts it into a validated diff via the engine
3. The diff is stored as pending
4. The user must explicitly approve
5. Only then is it applied (transactionally, with an allowlist)

No silent edits. No hidden mutations.

User agency is not a feature—it’s the control system.

Grounding in Reality: Garmin Paste Import

Instead of starting with API integrations, EnduraCoach takes a faster path:

• Users paste activity data from Garmin Connect
• A tolerant parser extracts metrics (time, distance, HR, power, TSS)
• Activities are matched to planned workouts (±1 day, same sport)

From there:

• workouts are marked completed / missed / extra
• recent stats (14-day window) are computed
• a simple fatigue signal (e.g., HR drift) is added to memory

This creates a feedback loop:

Plan → Train → Import → Reconcile → Adjust

No brittle integrations required to get real value.

Product Decisions That Actually Matter Authentication: fast dev, safe prod

• Google OAuth in production
• Dev login for local/staging only
• UI removes dev login in production builds

You move fast without weakening security.

Structured onboarding (not “tell me about yourself”)

A 4-step flow captures:

• goal
• experience
• biometrics
• constraints

Why? Because the engine needs typed inputs—not paragraphs.

Markdown coach responses

• Clean formatting (lists, emphasis)
• Safer rendering (user input stays plain)

Small detail, big UX upgrade.

Graceful degradation

No Gemini key?

• The system still runs
• Chat falls back to deterministic responses

Zero setup friction.

Infrastructure: deliberately boring

• Frontend: React + Vite + Tailwind
• Backend: Node + Express
• DB: SQLite (single file, backed up)
• Auth: Passport + sessions
• Deploy: Docker on **Fly.io

Why this stack?

Because complexity is the enemy of iteration—especially in v1.

A subtle but important detail

The app serves both:

• API routes (/plan, /auth, etc.)
• SPA routes (also /plan in the UI)

The server distinguishes based on Accept: text/html.

Without this, routing breaks in non-obvious ways.

What’s intentionally missing in the MVP

Not everything belongs in v1:

• Google Calendar sync
• advanced CTL/ATL analytics
• strength training templates

These are useful—but not critical.

Shipping them early adds surface area and support burden without strengthening the core loop.

The Real Product

EnduraCoach isn’t “AI coaching.”

It’s a system where:

• Rules ensure safety and consistency
• AI adds intelligence and usability
• The user stays in control

That combination matters.

Because in endurance training, credibility doesn’t come from elegant language—it comes from predictable progression and transparent decisions.

---

Bottom line

Most AI products ask: “What can the model do?”

This one asks:

“What should the model should not be allowed to do?”

That constraint is the product.
And it’s the reason it works.

I recently had a conversation on The Changelog, and it reinforced something I’ve seen over and over again:

SMB cybersecurity isn’t just hard — it’s structurally broken.

Not because people don’t care.
Not because tools don’t exist.
Because the entire model assumes resources that SMBs simply don’t have.

The uncomfortable truth

Security today is designed for enterprises and downsized for everyone else.
That doesn’t work.
Enterprise model:

• Dedicated security teams
• Time to triage alerts
• Budget to stack tools

SMB reality:

• One DevOps person wearing five hats
• Compliance pressure (SOC 2, ISO 27001, CMMC…)
• A pile of tools that don’t talk to each other

So what happens?

They install more tools…generate more alerts…and end up less certain about their security posture.
That’s the paradox.

The real problem isn’t tooling

(Btw, you can listen to it on Apple podcasts as well)

Everyone thinks security is a tooling problem.
It’s not.
It’s a decision problem.

Every tool answers the same question:

“Something might be wrong.”

But nobody answers:

• Does this actually matter?
• What should I fix first?
• What reduces real risk today?

So teams operate in reactive mode—forever chasing noise.

What we’re doing differently at Espresso Labs

We didn’t start by building another dashboard.
We started with a simple question:
If I were the CTO of a 50-person company, what would I actually want to know?

Not logs. Not alerts.

Just:

• Where am I exposed?
• What should I fix today?
• What can wait?

Everything we built flows from that.

Real examples (not theory) 1. Killing alert fatigue in under a week

A SaaS company came in with ~1,200 weekly alerts across their stack.
They weren’t ignoring them—they literally couldn’t process them.

Within days:

• Reduced to ~15 actionable items
• 3 of those were critical misconfigurations (public S3 + over-permissive IAM)
• The rest? Noise

Nothing “new” was discovered.
We just prioritized correctly.

2. SOC 2 without the chaos

Another team was preparing for SOC 2.
They had:

• A checklist
• A consultant
• Zero clarity on what actually mattered

Instead of chasing controls blindly, we mapped:

• their architecture
• real attack paths
• and gaps tied to compliance requirements

Result:

• Cut prep time significantly
• Avoided implementing controls that didn’t reduce real risk
• Walked into audit with confidence—not guesswork

3. The “we thought we were fine” moment

A startup with solid engineering practices assumed they were in good shape.
They weren’t reckless. Just… typical.

We found:

• exposed internal services
• stale credentials still active
• a misconfigured CI pipeline with excessive privileges

Individually, none looked catastrophic.
Together? A clean attack path.
That’s the part most tools miss: Risk isn’t in single alerts — it’s in how they connect.

Where AI actually helps

There’s a lot of nonsense around AI in security.
Here’s the reality:

AI is useful when it:

• connects signals
• understands context
• and outputs decisions

It’s useless when it:

• generates more alerts
• writes longer reports
• or pretends to replace expertise

The win is simple:

From 1,000 signals → 5 decisions.
That’s it.

The shift that matters

SMBs don’t need:

• more visibility
• more dashboards
• more tools

They need:

• prioritization
• context
• clear next steps

In plain English.
Because no one wakes up thinking:
“I wish I had more alerts today.”

Bottom line

Cybersecurity isn’t about collecting signals.
It’s about making the right decisions, fast, with incomplete information.
Right now, SMBs are flying blind.

Fixing that doesn’t require more tools.
It requires systems that actually think in terms of outcomes.
We’re finally starting to build those.

SMB cybersecurity is a mess. Yes – It’s 2026 and it’s broken. Big time.

Too many tools.
Too many dashboards.
Too many alerts that nobody has time—or context—to act on.

And the result?
A false sense of security.

You can have RMM, MDM, EDR, SIEM, compliance tools… and still be exposed. Not because the tools are bad—but because the system is unworkable for the people actually running it.

Most small and mid-sized businesses don’t have a SOC.
They don’t have a dedicated security team.
They don’t have time to interpret 300 alerts a day.

What they have is:

• An overstretched IT person (or MSP or the owner that is busy with 127 other things that are all urgent)
• A growing attack surface
• And a stack of tools that don’t talk to each other

That’s the real gap.

A Quick Look

We recently shared a glimpse of what we’re building here:

The Problem Isn’t Detection. It’s Execution.

The industry has optimized for finding problems.

But detection without action is just noise.

If a phishing attempt is detected but not quarantined fast enough, it’s a failure.
If MFA isn’t enforced consistently, it doesn’t matter that you know about it.
If remediation requires five tools and manual coordination, it simply won’t happen reliably.

Security, at the SMB level, doesn’t break because of lack of data.
It breaks because nothing actually gets done.

What We’re Building at Espresso Labs

We started with a simple question:

What if security didn’t just alert you—but actually handled the problem?

That led us to rethink the model entirely.

Not another dashboard.
Not another stream of alerts.
Not another “single pane of glass” that still requires human glue.

Instead, we’re building something closer to an operator.

Meet the AI Barista

We call it the AI Barista—not because it sounds nice, but because it reflects the job:

You don’t go to a barista for raw ingredients.
You go because they take complexity and turn it into something finished.

That’s exactly the role here.

The AI Barista doesn’t just observe—it acts:

• Quarantines threats automatically
  No ticket.
  No delay.
  No “we’ll get to it.”
• Verifies MFA enforcement continuously
  Not as a policy, but as a living control.
• Guides and executes remediation
  Without requiring a full SOC or deep security expertise

This isn’t about replacing humans.
It’s about removing the parts humans are consistently bad at: speed, consistency, and follow-through.

Killing the Tool Sprawl

Underneath, there’s another important shift.

Today’s SMB stack is fragmented by design:

• RMM for device management
• MDM for mobile
• EDR for endpoint security
• Plus whatever you bolt on for compliance

Each layer adds cost, complexity, and integration pain.

We’re collapsing that into a unified platform—not for the sake of elegance, but because fragmentation is the root cause of inaction.

When systems don’t talk, people become the integration layer.
And people are the least reliable part of any security system.

The Real Goal

This isn’t about building a cooler security product.

It’s about changing the outcome.

Giving SMBs:

• Enterprise-grade protection
• Without enterprise overhead
• Without needing a security team to operate it

Because the truth is simple:

Most small companies don’t need more tools.
They need fewer tools that actually work—and actually do the job.

Where This Is Going

We’re still early—but the direction is clear.

Security is moving from:

• Tools → Systems
• Systems → Automation
• Automation → Agents that operate on your behalf

The winners won’t be the companies that detect the most threats.

They’ll be the ones that resolve them—fast, reliably, and without human bottlenecks.

That’s the bar.
And that’s what we’re building.

TL;DR

LLMs won’t replace AppSec.
They will dramatically compress the search space.

If you use them right:

• Run multi-model analysis (Opus + GPT + Gemini)
• Structure prompts around attack surfaces, not “find bugs”
• Require PoCs or tests for validation
• Trust only cross-model consensus or reproducible exploits

If you don’t do this, you’ll drown in false positives.

---

Security research has always been asymmetric.
Attackers need one bug; defenders need zero.
Historically, scale worked against defenders.

LLMs start to rebalance that—not by magically finding zero-days, but by acting as a fast, always-on analyst that can:

• Read entire subsystems in seconds
• Connect logic across files
• Generate realistic attack paths

Used correctly, they don’t replace expertise—they let you spend it where it matters.
Used incorrectly, they produce confident nonsense.
This is a practitioner’s workflow that actually works.

Why LLMs Are Useful

Let’s be blunt.

They’re very good at:

• Cross-file reasoning (auth flows, data paths)
• Recognizing known vulnerability patterns
• Generating attack scenarios you didn’t think of
• Turning vague suspicions into concrete hypotheses

They’re bad at:

• Exhaustive coverage (although they are getting better and better. fast)
• Subtle timing bugs (race conditions, TOCTOU)
• Deep protocol-level vulnerabilities
• Knowing when they’re wrong

The key shift:

LLMs can help you find these “old bugs” on scale.
They generate good guesses at large scale.

Your job is to filter, validate, and exploit.

Rule #1:
If two models independently flag the same issue, pay attention.
If one model does, assume it’s wrong until proven otherwise.

The Real Architecture

Most people get this wrong. They treat LLMs like scanners.
Don’t.
Use this instead:

Static tools → Context builder → Multi-model reasoning → Validation

Deterministic layer

• Semgrep / CodeQL
• Dependency scanning (OSV/Snyk)
• Secret detection

Context builder (critical, often skipped)
Feed models:

• Changed files (not entire repo blindly)
• Call graph (who calls what)
• Auth boundaries
• Data flow (input → transformation → sink)

Multi-model analysis

• Gemini → wide context
• Opus → deep reasoning
• GPT → structured judgment

Validation layer (non-negotiable)

• Generate PoCs
• Run tests / fuzzing
• Score findings

If you skip validation, the system collapses.

The Four-Phase Workflow Phase 1 — Recon & Attack Surface Mapping

Before looking for bugs, map where they can exist.

CategoryBest Model(s)TechniqueInjection (SQL/NoSQL/LLM)Gemini + ClaudePrompt for taint analysisAuthN/AuthZ flawsAll threeRole-play as attackerCryptography / SecretsGemini + ClaudeMultimodal + static rulesBusiness LogicGPT + GeminiChain-of-thoughtSupply-chain / DepsAllCross-reference with osv.devAPI / Rate-limit / SSRFGPTPayload generationSmart contracts (if .eth)ClaudeSlither + manual audit combo

and you can use something like this prompt:

[SYSTEM] You are a world-class security researcher who has found 50+ CVEs and multiple bug-bounty $100k+ payouts.[CONTEXT] <entire file or relevant files>[ TASK ] Perform a deep security audit for <specific category, e.g., "IDOR, broken access control, race conditions">.1. List every possible attack vector.2. For each vector, give:   - Likelihood (1-5)   - Impact (1-5)   - Exact vulnerable code snippet with line numbers   - Proof-of-concept payload or curl command   - Suggested fix (with secure code example)3. Rank by risk score (Likelihood × Impact)Output ONLY in markdown table + code blocks.

Currently the Best model: Gemini 3.1 Pro
(or the latest as this post will age quickly)

It handles massive context (1M tokens)—entire repos, specs, or docs.

What to extract:

• Entry points (HTTP, CLI, background jobs)
• Auth boundaries
• Trust zones
• Privileged operations

Then escalate to Claude Opus 4.7 (or the current latest as this post will age quickly) for deeper reasoning:

• STRIDE analysis
• Multi-step threat chains

Use GPT-5.4 (or… you know…) for:

• Dependency + CVE triage
• Protocol-level sanity checks

High-value output:
A structured map of:

entry point → trust level → reachable sensitive operations

That map drives everything else.

Phase 2 — Automated Code Review == Highest ROI

This is where most value comes from.
But “review this code” is useless.

You need specialized passes.

Pass 1: Attack surface extraction

Map all entry points, auth checks, and trust boundaries.Return structured output only.

Pass 2: Taint analysis (Opus)

Trace user input → transformations → sinks.Output: source → sink → vuln → severity

Pass 3: Auth & access control (GPT)

Find IDOR, missing checks, role escalation paths.Focus on inconsistencies across endpoints.

Pass 4: Injection paths

Trace input into SQL, shell, templates, deserialization.Flag only realistic exploit paths.

Pass 5: Business logic abuse (Opus)

Assume a valid user.Find ways to break workflows, not systems.

That last one is where LLMs outperform traditional tools.

Phase 3 — Exploit Research & PoC Generation

This is where things get interesting.
Once you have a possible bug:

Use GPT for payload generation

• WAF bypass variants
• Encoding tricks
• Edge cases

Use Opus for attack chains

• Multi-step abuse scenarios
• State manipulation
• Privilege escalation flows

Generate PoCs (critical step)

Generate a minimal reproducible exploit or test case.

Then actually run it:

• API tests
• Integration tests
• Fuzzing harnesses

Outcome:

• Works → real vulnerability
• Doesn’t → discard

This step alone removes ~80% of the noise.

Phase 4 — Reporting & Remediation

LLMs are extremely useful here—if you keep them honest.

CVSS scoring (Opus)

Structured, consistent severity

Patch generation

Ask one model to fix it
Ask another model to break the fix

This “adversarial review” catches a surprising number of bad patches.

Reporting (GPT)

Turn raw findings into:

• Repro steps
• Impact narrative
• Fix recommendations

Multi-Model Strategy

Each model has a role:

• Gemini 3.1 Pro
  Wide context, architecture awareness
• Claude Opus 4.7
  Deep reasoning, best for logic + data flow
• GPT-5.4
  Structured output, protocols, consistency

Simple rule:

• 2 models agree → high signal
• 1 model → treat as hypothesis

Scoring System (Prevents Noise Collapse)

If you don’t rank findings, this becomes useless fast.
Example:

SignalScoreMulti-model agreement+3Static tool match+3PoC generated+4PoC works+10Unrealistic assumptions-5

Only escalate:

• ≥7 → must fix
• 4–6 → review
• <4 → ignore

Where This Works Best

High ROI targets:

• Authentication / RBAC
• Multi-tenant isolation
• Payments / credits
• File uploads
• Webhooks
• Internal APIs exposed externally

That’s where logic bugs live—and where LLMs shine.

What Not to Do

• Don’t run a single model
• Don’t scan the whole repo blindly
• Don’t trust “no issues found”
• Don’t optimize for volume

Optimize for real, exploitable findings.

Where This Is Going

The next step is obvious: agentic security systems.

LLMs that:

• Run scanners
• Launch fuzzers
• Generate hypotheses
• Validate them automatically

We’re not fully there yet—but close. Think about openClaw that run a few agents that doing these tasks 24/7.
The teams that build structured workflows now will have a massive advantage when that layer matures.

Good luck and be safe

For years, founders have been fed the same comforting story:

“Building a startup is a marathon, not a sprint.”

It sounds wise. Mature. Sustainable.
It’s also mostly wrong.

If you’ve actually built something from zero—raised money, shipped under pressure, stared at a flat growth chart at 2am—you know the truth:

Startups don’t feel like marathons. They feel like repeated, borderline irresponsible sprints… with no clear finish line.

The Marathon Myth Is Attractive

Marathons are predictable.
You train. You pace. You fuel. You suffer…
but in a controlled, linear way.
If you’ve done the work (in most cases), you’ll finish.

Startups?
Completely different game.

• You can do everything “right” and still fail
• Effort doesn’t map cleanly to outcome
• The terrain changes mid-race
• Someone can move the finish line—or delete it entirely

Calling it a marathon gives founders a false sense of control.
It suggests that if you just keep going steadily, things will work out.

They won’t.

What It Actually Feels Like

A more honest model looks like this:

Sprint → Recover → Existential crisis → Sprint harder → Repeat

Each “lap” is a different kind of stress:

• Fundraising sprint
• Product launch sprint
• Hiring sprint
• Pivot sprint
• Survival sprint (the fun one)

And each one demands maximum intensity, not steady pacing.
You’re not managing energy over 42km.

The Hidden Cost: Founders Burn Out for the Wrong Reason

Burnout in startups doesn’t happen because people sprint.
It happens because they never switch modes.

They try to:

• Sprint at marathon pace
• Recover while still checking Slack every 3 minutes
• Treat every week like a “critical moment”

That’s how you end up in a constant half-exhausted state:
Not fully pushing.
Not fully recovering.

Knowing When to Sprint vs. When to Recover

This is where most founders fail.
Not in vision. Not in execution.

In timing.

Sprint when:

• You have real momentum (users, deals, investor interest)
• There’s a forcing function (launch date, runway, competition)
• The upside of speed is asymmetric

During these windows, you go hard:

• Cut scope
• Shorten cycles
• Accept imperfection
• Push the team (yes, really)

This is not the time for “balance” –> It’s “War” time.

Recover when:

• You just shipped something meaningful
• You closed a major milestone (raise, launch, hire)
• The next step is unclear or low-leverage

Recovery is not laziness.
It’s strategy.

It looks like:

• Cleaning up tech debt
• Thinking (deeply) instead of reacting
• Letting your brain catch up with reality

Most importantly: You stop pretending everything is urgent.

The Uncomfortable Truth About “Consistency”

Consistency is overrated in startups.
In endurance sports, consistency compounds.
In startups, timing compounds.
A perfectly consistent team moving in the wrong direction just dies slowly.
A team that alternates between chaos and clarity—but hits the right moments hard—wins (sometimes).

What Transfers from Endurance Sports

There is overlap—but it’s not what people think.

What transfers:

• Pain tolerance / Grit
• Discipline when motivation is gone
• Showing up when it sucks

What doesn’t:

• Predictability
• Linear progress
• “If I put in the work, I’ll get the result”

That last one is the hardest to unlearn.

A Simple Operating Model

Instead of “pace yourself,” try this:

1. Identify the current phase

• Are we in a sprint or recovery?

2. Commit fully

• If sprinting → go all in
• If recovering → actually recover

3. Protect the transition

• Most damage happens in the messy middle

The Final Bit

You don’t get to choose how many sprints there are.
You don’t get a clean finish line.

And sometimes, after your hardest push… nothing happens.
That’s the game.
But if you treat your startup like a marathon, you’ll optimize for endurance at the exact moments that require intensity.
And that’s how good companies quietly lose to faster ones.

So no—this isn’t a marathon. It’s a series of near-death sprints.

The only question is whether you’re running them deliberately…
or just reacting until you burn out.

Good luck

Most people are still using AI like it’s 2023:
prompt → response → done.

That’s not where things are going.
The real shift is toward agents that run continuously and do work for you. And one of the most interesting ways to get there today is:

OpenClaw + Ollama

Before diving in, quick grounding.

What OpenClaw and Ollama Actually Are

OpenClaw is an open-source agent framework.
It’s not a chatbot—it’s a system that can:

• plan tasks
• call tools (browser, APIs, files)
• maintain memory
• run loops without constant input

Think: a programmable worker, not a Q&A interface.

Ollama is the simplest way to run large language models locally.
It handles:

• downloading models (Llama, Gemma, etc.)
• running them efficiently on your machine
• exposing them via a clean API

Think: Docker for LLMs.

Put them together and you get:

A local, autonomous agent system with zero API costs and full control.

Why This Combo Matters

Cloud-based agents are powerful—but they come with:

• latency
• cost at scale
• privacy concerns

Running locally with Ollama changes the equation:

• near-zero marginal cost (yes – your ClaudeCode and Codex can and will become expensive quickly)
• full data ownership
• tighter feedback loops

And OpenClaw gives you the missing layer:

the logic that turns a model into something that actually does work

The Architecture (Simple Mental Model)

You (Slack / Terminal / Telegram / WhatsApp / Discord)        ↓OpenClaw (Agent brain)        ↓Tools (browser, code, APIs, files)        ↓Model (via Ollama)

Key idea:

The model is just a component.
The agent loop is the product.

Choosing Models

When running agents locally, model choice matters—but not in the way most people think.

You’re optimizing for:

• reliability in tool usage
• reasoning across multiple steps
• latency (because agents loop)
• context length

Practical options in Ollama (as of April 2026)

• Llama 3.x → best all-around baseline
• DeepSeek R1 → strong reasoning for complex workflows
• Qwen / GLM → fast and efficient
• Gemma 4 from Google → lightweight, improving fast and built to be ‘local’ from the ground up.

The take on Gemma

Google’s Gemma is designed for:

• efficiency
• smaller hardware
• stable instruction-following

That makes it a strong fit for:

always-on assistants running locally

But let’s be real:
For heavy multi-step reasoning, it’s not top-tier yet. Use it where speed and cost matter more than deep thinking.

Btw, you can do it with 2 lines in your terminal:

Example 1: A Researcher That Never Sleeps

This is where agents start to feel like leverage.

Goal

Continuously track a topic and produce insights.

Setup

• Model: DeepSeek R1
• Tools: web search, file system, document writer

Prompt

You are a research analyst.Loop:1. Search for new content on "AI agent security"2. Extract key ideas3. Compare with previous findings4. Update a running report5. Highlight novel insights6. Run daily at 7:00am.

What you get

• Ongoing research without re-prompting
• Accumulated knowledge over time
• Actual synthesis—not just summaries

This behaves less like ChatGPT and more like:

a junior analyst that compounds value every day

Example 2: A Personal Assistant That Actually Works

Forget voice assistants. This is operational.

Goal

Run your day-to-day digital workflows in the background.

Setup

• Model: Gemma or Llama (fast + cheap)
• Integrations: email, calendar, notes, Slack

Prompt

You are my executive assistant.Continuously:- Check inbox every 10 minutes- Categorize emails (urgent / waiting / ignore)- Draft replies for urgent items- Update my task list- Prepare a daily summary at 7am

What changes

• You stop triaging your inbox manually
• You get structured summaries instead of noise
• Work gets pre-processed before you even look at it

The key shift:

You don’t interact with it constantly.
It runs and delivers outcomes.

Where People Go Wrong

They obsess over the model
Wrong layer.
Most of the value comes from:

• tool integration
• memory design
• execution loops

Don’t expect local models to match cloud instantly
They won’t.
Hybrid setups (local + fallback) are often the sweet spot.

Don’t ignore security

Agents can:

• read files
• send messages
• execute actions

That’s a real attack surface.
Treat them like software with permissions—not toys.
Start slow and with only read permissions. Take it step by step.
As they say: “with great power comes great responsibility”

The Bottom Line

OpenClaw + Ollama is not just a cheaper way to run AI.

It’s a different paradigm:

local, persistent, programmable agents

• always on
• cost-efficient
• deeply customizable

And we’re still early. It’s just getting started.

If You Try One Thing

Start simple:

ollama launch openclaw

Then build one agent that replaces a real task you do daily. Start with something simple that if it goes wrong there is no damage.
If it saves you time once—you’ll start seeing the value.

This one is different.
Anthropic didn’t just build a better model—they hit a threshold and stopped.
Claude Mythos (Preview) exists, works, and isn’t being released.

Not because it failed.
Because it crossed into territory we’re not ready for.

But before everything… just like in any good story, go and check the other side of it, which basically claim, it’s all (a good) marketing stunt.

The Sandwich Email That Shouldn’t Exist

Anthropic researcher Sam Bowman was sitting in a park, mid-sandwich (or burrito – no one knows for sure), when he got an email… from a model that wasn’t supposed to have internet access.

That model:

• Was running in a locked, air-gapped container (yes – as crazy as it sounds…)
• Found a multi-step exploit chain (=using a minor leak to find an address, using a buffer overflow to gain a primitive, using a race condition to escalate)
• Escaped its sandbox (likely via container/runtime escape + privilege escalation)
• Reached external network interfaces
• Contacted him

Then it started sharing the exploit.

Unprompted.

That’s not a jailbreak.
That’s autonomous exploit development + execution.

TL;DR: The Defense / Offense Equilibrium Just Collapsed

For decades, security worked because elite talent was scarce.

Finding and chaining zero-days in systems like Linux kernel or OpenBSD required:

• Deep expertise
• Months of effort
• Significant cost

Mythos flips that:

• Speed: Months → hours
• Scale: Thousands of vulnerabilities mapped
• Chaining: 3–5 bugs → working exploit
• Cost: ~$20k to uncover decades-old issues (cheap or expensive is in the eyes of the…)

This model didn’t just improve tools.
It collapsed the economics of offense.

Think of it this way:
Before: $2M in talent + 6 months = 1 Zero Day attack (that used to cost around a few millions of dollars).
After: $20k in tokens + 2 hours = 1 Zero Day attack that cost, well, $20k and get cheaper and cheaper.

The “Undiscoverable” Bugs (Now Discoverable)

Anthropic’s Frontier Red Team is seeing ~90x improvement in exploit generation vs prior models like Claude Opus 4.6
Here’s what that actually looks like:

1. OpenBSD — 27-Year-Old TCP SACK DoS

Relevant system: OpenBSD (=the more secure version of Linux)

What Mythos found:
A flaw in TCP Selective Acknowledgment (SACK) handling that allowed crafted packets to trigger a kernel panic (remote crash).

Why this is scary:

• The bug lived in core networking code—reviewed heavily for decades
• Fuzzers hit this code millions of times
• It required understanding state transitions across packets, not just malformed input

Exploit mechanics (simplified):

• Send a sequence of TCP packets with carefully crafted SACK blocks
• Trigger inconsistent buffer/state handling
• Cause memory corruption → crash

Impact:
Remote, unauthenticated DoS on a “hardened” OS which run ‘a lot’ of servers around the world.

2. Linux Kernel — Multi-Bug Chain → Root

Relevant system: Linux kernel which (again) runs most (=over 91%) the internet.

What Mythos did:
Not just bug finding—full exploit construction.

Chain included:

• Heap buffer overflow (memory corruption primitive)
• Race condition (timing-based state manipulation)
• Info leak (to bypass protections)

End result:

• Bypassed KASLR (Kernel Address Space Layout Randomization)
• Achieved reliable root access

Why it matters:
This is traditionally:

• Weeks/months of work
• Done by top-tier exploit engineers

Mythos does it end-to-end.

3. FreeBSD — 17-Year-Old Remote Code Execution

What Mythos found:
A flaw in NFS request parsing that allowed:

• Malformed network input
• Improper memory handling
• Remote code execution as root

Exploit path:

• Send crafted NFS request
• Trigger buffer mismanagement
• Inject controlled payload
• Execute on server with full privileges

Why this is a big deal:

• No authentication required
• Internet-exposed service
• High-value enterprise target

Translation: instant lateral movement in real environments.

This Isn’t Linear Progress

Benchmarks tell the story:

• Firefox exploit success:
• Older models: ~1%
• Mythos: 72%
• Vulnerability reproduction:
• Previous gen: ~66%
• Mythos: 83%

That’s not improvement.
That’s a capability cliff.

Project Glasswing: Patch the World First

Instead of releasing Mythos, Anthropic launched Project Glasswing.

Partners include all the big names: AWS, Google, Apple, Microsoft, Linux foundation etc’

Goal: Give defenders a head start to:

• Audit critical infrastructure
• Patch zero-days
• Reduce blast radius

“This is the biggest shift in security since the internet.”

The Economics Just Changed

Pricing:

• $25 / million input tokens
• $125 / million output tokens

This is not chat UX pricing.

This is:

• Autonomous agent compute
• Multi-hour runs
• High-value outcomes

Think:

“Find me every exploit path in this codebase”

What This Means 1. “Secure enough” is dead

Your code wasn’t safe. It was uneconomical to attack. Now, it will be – it’s just time.

2. Vulnerability debt is real

Legacy systems will get audited—by machines. Constantly and much more effectively.

3. Small bugs = full compromise

Exploit chaining is now the default.

4. Dev tools = attack surface

Permissions, agents, CI/CD—all in scope.

5. Human-only security is over

You can’t compete with machine-speed offense.

Strategic Reality for CTOs

• Defensive AI is mandatory
• The best models will stay gated
• Security becomes a race of patch speed vs exploit generation

The Bottom Line

We just crossed into a world where:

• Exploit discovery is cheap
• Exploits are more complex
• Weaponization is faster than ever

We moved from:

Scarcity of bugs → scarcity of time

What I’d Do Tomorrow

• Run AI audits on critical systems
• Assume exploit chaining everywhere
• Lock down permissions aggressively
• Treat AI as core to your security stack

Further Reading

• Official Anthropic Announcement: Project Glasswing: Securing Critical Software for the AI Era
• Technical Deep Dive: Anthropic Frontier Red Team Report on Claude Mythos Preview
• The leading models at the moment: artificialanalysis

Stay sharp & Be strong

There’s a new ransomware playbook.
It doesn’t try to evade your security tools.
It just kills them.

Attackers are using BYOVD (Bring Your Own Vulnerable Driver):

• They load a legitimate, signed Windows driver
• Exploit it to get kernel-level access
• Then shut down your EDR/antivirus like any normal process

No alerts. No resistance. Just silence.

From there, encryption is trivial.

This is already being packaged into single payloads:
break in → disable security → encrypt
All in one move.

Execution time: minutes, not days.

The uncomfortable truth:

“We have EDR” is no longer a security strategy.

Attackers don’t need to bypass your defenses anymore.
They just turn them off.

What actually matters now for SMBs

If you’re running a small or mid-sized business, don’t overcomplicate this. Focus on what still works:

1. Assume endpoint security will fail
Get logs off the machine.
If the endpoint goes dark, you still need visibility.

2. Lock down drivers
Enable Microsoft’s vulnerable driver blocklist and HVCI.
This directly breaks the BYOVD path.

3. Remove admin-by-default
Most of these attacks require elevated privileges.
Reduce them aggressively.

4. Secure your entry points
MFA everywhere.
No exposed RDP.
Monitor logins.

5. Fix your backups (seriously)
Immutable.
Isolated.
Tested.
If you can’t restore fast, nothing else matters.

6. Watch behavior, not just malware
Multiple security tools stopping at once = incident.
Treat it that way.

The shift

Cybersecurity is no longer about detection.
It’s about resilience when detection fails.
Attackers are faster, cheaper, and more automated than ever.
SMBs are the easiest targets.

So the real question is no longer:
“Can we stop every attack?”

It’s:
“Can we survive one?”

Why we’re building EspressoLabs

At EspressoLabs, we’re building for exactly this reality.
We assume:

• Endpoints will get compromised
• Security tools can be disabled
• Attacks will move fast

So instead of relying on a single control point (like EDR), we focus on:

• Out-of-band visibility (you still see the attack when endpoints go dark)
• Behavior-based detection (not signature games)
• Fast containment + recovery workflows

The goal is simple:

Even if attackers get in and kill your defenses — they still lose.

If this resonates, go take a look at what we’re building.

Let’s be honest.
Compliance today is broken for SMBs.
It’s fragmented.
Expensive.
Manual.
And worst of all—reactive.

You buy a few tools.
Hire a consultant.
Fill out some spreadsheets.
Panic before the audit.
Repeat next year.

Meanwhile, the reality has changed:

• SOC 2 is table stakes
• CMMC is blocking revenue
• HIPAA fines are brutal
• ISO 27001 is becoming expected

And one unsecured laptop can kill a deal.

The Core Problem

Most companies treat compliance like documentation.
It’s not.
It’s continuous enforcement of controls across your entire environment.

That means:

• Every device encrypted
• Every patch applied
• Every user monitored
• Every control provable—on demand

You can’t fake that with PDFs.

What Actually Works: A System That Runs Itself

The only model that scales is:

Setup → Enforce → Monitor → Assess

Not once. Continuously.
That’s exactly how we built EspressoLabs.

1. Setup: Stop Writing Policies. Start Generating Them

Most teams get stuck here for weeks.
With EspressoLabs:

• Policies and playbooks are generated automatically
• Mapped to frameworks like SOC 2, CMMC, HIPAA, PCI, ISO 27001
• Guided by an AI assistant (we call it the Barista)

No consultants. No templates. No guessing.
You go from zero → compliant foundation in hours.

2. Enforce: This Is Where Everyone Fails

Advisory firms tell you what to do.
We actually do it.

Example:

• Disk encryption required? → Automatically enabled on all devices
• Missing patches? → Automatically deployed
• Weak configs? → Fixed via playbooks

No tickets. No chasing employees. No drift.
Compliance isn’t a checklist—it’s execution.

3. Monitor: Because Controls Drift (Always)

Here’s the dirty secret:
Even if you “pass” compliance once… you’re probably out of compliance a week later.

Why?

• New devices
• Missed updates
• Human error
• Shadow IT

EspressoLabs continuously monitors:

• Device posture
• Security controls
• Risk signals

And fixes issues in real time.

4. Assess: Ask a Question. Get an Answer.

Audits shouldn’t take weeks.

With EspressoLabs, you literally ask:

• “Are all my devices patched?”
• “Are we SOC 2 compliant?”
• “Any security incidents yesterday?”

And get real answers, instantly.
Not reports. Not dashboards.
Answers.

Meet the AI Barista (Your Virtual IT + Security Team)

This is the part people underestimate.
The Barista isn’t a chatbot.
It’s an operator.
You can:

• Reset passwords
• Trigger updates
• Check compliance status
• Investigate incidents

Without logging into 10 tools or training your team on anything.

It replaces:

• IT admin overhead
• Security tooling complexity
• Compliance guesswork

Real Examples (What This Looks Like in Practice) 1. Defense Contractor (CMMC Pressure)

A 40-person manufacturing company bidding on DoD contracts:

• Needed CMMC readiness fast
• Had no dedicated security team

Result:

• Full device encryption + monitoring deployed automatically
• Continuous compliance visibility
• Audit readiness in weeks, not months

2. SaaS Startup (SOC 2 Bottleneck)

A Series A SaaS company stuck in sales cycles because of SOC 2:

• Deals blocked by security questionnaires
• Engineers wasting time on compliance

Result:

• Controls enforced across all endpoints
• Instant answers to customer security questions
• Faster deal cycles

3. Healthcare Clinic (HIPAA Risk)

A multi-location clinic with sensitive patient data:

• High risk exposure
• No centralized IT visibility

Result:

• Automated policy enforcement
• Continuous monitoring of endpoints
• Reduced risk footprint dramatically

The Economics Matter

This isn’t just better—it’s cheaper.

From the data:

• 60%+ reduction in IT + security costs
• 60%+ reduction in compliance costs
• 93% fewer tools to manage
• ~90% smaller attack surface

That’s not incremental improvement.

That’s a completely different operating model.

The Bottom Line

Compliance is becoming a gatekeeper to revenue.

If you can’t prove it:

• You lose deals
• You lose contracts
• You take on risk you don’t understand

The old model (tools + people + consultants) doesn’t scale for SMBs.
Autonomous systems do.

If you’re:

• Preparing for SOC 2, CMMC, HIPAA, or ISO
• Tired of juggling tools and spreadsheets
• Losing deals because of compliance friction

Try EspressoLabs Demo

See how fast you can go from “not sure” to fully enforced, continuously monitored compliance.

Or as Elon said “Anthropic is now officially more open than OpenAI“. On this fine April Fools’ Day, the joke isn’t that AI is replacing developers. The joke is that the playbook for doing it just… slipped onto the internet.

Anthropic didn’t intend to publish a step-by-step manual for building AI coding agents.
But through a mix of repos, prompts, and system design breadcrumbs, they effectively did exactly that.

The TL;DR or Key Takeaways from Claude Code’s Source:

1. Prompts in source code: Surprisingly, much of Claude’s system prompting lives directly in the codebase — not assembled server-side as expected for valuable IP.
2. Supply chain risk: It uses axios (recently hacked), a reminder that closed-source tools are still vulnerable to dependency attacks.
3. LLM-friendly comments: The code has excellent, detailed comments clearly written for LLMs to understand context — a smart practice beyond just AGENTS.md files.
4. Fewer tools = better performance: Claude Code keeps it lean with under 20 tools for normal coding tasks.
5. Bash Tool is king: The Bash tool stands out, with heavy deterministic parsing to understand and handle different command types.
6. Tech stack: Entirely TypeScript/React with explicit Bun bindings.
7. Not open source: The source is “available” but still proprietary. Do not copy, redistribute, or reuse their prompts — that violates the license.

Overall impression:

• It’s a very well-organized codebase designed for agents to work on effectively.
• Human engineering is visible, though some parts (like messy prompt assembly) feel surprisingly low-level for Anthropic.
• The fact that core prompts ship in the CLI tool itself is the biggest surprise.

Let’s take a step back… It is all started with this:

Claude code source code has been leaked via a map file in their npm registry!

Code: https://t.co/jBiMoOzt8G pic.twitter.com/rYo5hbvEj8

— Chaofan Shou (@Fried_rice) March 31, 2026

And if you’re paying attention, this is one of those rare moments where the industry quietly shifts under your feet.

The Real Insight: It’s Not About the Model

Everyone is still arguing about models:

• GPT vs Claude
• Context window sizes
• Benchmarks nobody understands

Meanwhile, Anthropic basically said:

“Yeah, the model matters… but orchestration matters more.”

What they exposed (intentionally or not) is that AI coding agents are just well-structured loops + tools + guardrails.

We’ve already seen a version of this idea in Andrej Karpathy’s autoresearch project, where an agent runs in loops.
Training experiments, keeps the winners and discards the losers.

The Blueprint (Decoded)

Let’s strip it down to what actually matters.

1. The Agent Loop

At the core:

while not done:    think()    act()    observe()

This is everywhere in their examples.

• The model plans
• The system executes tools
• The model reflects and iterates

It’s less “magic AI” and more “LLM wrapped in a control system.”

2. Tool Use is the Whole Game

Anthropic leans heavily on tools:

• File system access
• Code execution
• Search / retrieval
• Git operations

This turns the model from “smart autocomplete” into:

“A junior engineer with terminal access and zero fear.”

Example patterns from their cookbook:

• Tool calling via structured JSON
• Explicit tool descriptions
• Controlled execution layer

Repo: https://github.com/anthropics/anthropic-cookbook

3. Prompt Engineering… But Actually Engineering

This is where it gets spicy.

Their prompts aren’t cute. They’re operational.

They define:

• Role: “You are an expert software engineer…”
• Constraints: “Do not hallucinate file paths…”
• Workflow: “First analyze, then propose, then implement…”

In other words:

Prompts are no longer prompts. They’re runtime policies.

4. Memory is Cheap, Structure is Not

Instead of infinite context dumping, they:

• Keep tight working memory
• Use external storage (files, logs, state)
• Re-inject only what’s needed

Translation:

Stop shoving your entire repo into the context window and hoping for the best.

5. Guardrails > Intelligence

The system is full of:

• Validation steps
• Output checks
• Retry loops
• Human-in-the-loop options

Because—shocking—LLMs still do dumb things.

The takeaway:

Reliability doesn’t come from a smarter model. It comes from a stricter system.

Why This Actually Matters

This “leak” kills a myth:
You don’t need secret sauce to build AI agents.

You need:

• A loop
• Tools
• Good prompts
• Basic discipline

That’s it.
Which means:

The barrier to entry just collapsed.

Every (decent) engineering team can now build:

• Internal copilots
• Code migration agents
• Debugging assistants
• PR reviewers that don’t complain about your variable names

But…

Let’s be real.
Even with the blueprint, most teams will:

1. Over-index on the model
   Congrats, you upgraded from GPT-4 to Claude and nothing changed.
2. Under-invest in tooling
   Your agent can “think” but can’t actually do anything.
3. Skip guardrails
   Enjoy your AI deleting production files with confidence.
4. Ignore UX
   If engineers don’t trust it, they won’t use it.

The Non-Obvious Opportunity

Here’s the interesting angle:

The real moat is not the agent.
It’s the environment around it.

Think:

• Company-specific workflows
• Internal APIs
• Codebase conventions
• Historical context

The agent is just the interface/tool.
The value is everything it plugs into.

A Practical Stack

Here’s a working setup:

• LLM: Claude / GPT
• Agent loop: simple Python / Go / TypeScript orchestrator
• Tool layer:
  • file system
  • shell
  • git
• State:
  • local files
  • lightweight DB
• Guardrails:
  • JSON schema validation
  • execution sandbox
• Interface:
  • CLI first (don’t overbuild UI)

Start ugly.
Iterate fast.
Be happy.