Tag: automation

  • You Don’t Deploy AI Agents Anymore — You Hire Them

    Yesterday, monday.com launched something called Agentalent.ai — a managed marketplace where enterprises can discover, evaluate, and “hire” AI agents for defined business roles. Not install. Not deploy. Hire.

    You post a role. You review qualified agents. You select based on task fit, budget, and operational readiness. Pricing starts around $2,000 a month per agent. They launch with 17 agents available. Built in collaboration with AWS, Anthropic, and Wix.

    If you’re a CFO and that doesn’t make your headcount model twitch, you’re not paying attention.

    The Language Shift That Matters

    I’ve been building with AI agents for the best part of two years now — wiring up Claude to handle research tasks, automating financial reporting pipelines, getting agents to do the kind of grunt work that used to eat a junior analyst’s entire Tuesday. But the framing has always been tooling. You set up an agent like you’d set up a spreadsheet macro. It’s a thing on your computer.

    What monday.com has done — deliberately, with their HR-style language — is shift the frame from tools to workers. And that’s not just marketing fluff. It’s the conceptual bridge that will get the rest of the C-suite to finally understand what’s happening.

    A Belitsoft report published this weekend puts numbers on it: the average enterprise now runs 12 AI agents. Twelve. And that’s expected to hit 20 by 2027. But here’s the kicker — half of those agents operate completely alone, unconnected to any other agent or system. They’re doing their little jobs in their little silos, and nobody’s orchestrating the whole thing.

    Sound familiar? It should. That’s exactly what happens when a company hires people without a coherent operating model. You end up with twelve contractors, half of whom don’t talk to each other, doing overlapping work with no shared context. I’ve walked into PE portfolio companies that look exactly like this — except with humans.

    The CFO’s New Headcount Problem

    Here’s where it gets interesting for anyone sitting in a finance seat. When an AI agent costs $2,000 a month and can do the work of a task that previously required a $6,000/month contractor, that’s a straightforward business case. Any CFO can model that. The ROI practically draws itself.

    But the real question isn’t “should we hire the agent?” It’s “how do we account for a workforce that’s now 30% software?”

    Think about what sits in your headcount model today. Salaries, employer NI, pension contributions, benefits, training costs, recruitment fees. Now think about what sits in your AI agent budget. SaaS subscriptions, API usage fees, compute costs, maybe some integration consulting. These two things live in completely different cost categories, get approved through different processes, and are managed by different people. But they’re increasingly doing the same work.

    In the PE world I operate in, headcount is one of the first things a new investor scrutinises. “What’s your revenue per head?” “What’s your fully-loaded cost per FTE?” These metrics are foundational to how value creation plans get built. But nobody’s asking “what’s your revenue per agent?” yet. And they should be, because if you’re running 12 agents and growing, that’s a material line in your operating model that isn’t being tracked like one.

    The Coordination Tax

    The Belitsoft finding that half of deployed agents work alone is, I think, the most important data point in their entire report. It mirrors what I’ve seen first-hand. Companies get excited, they spin up agents for customer support, for code review, for data entry, for reporting — and each one works reasonably well in isolation. But the value compounds when agents talk to each other, and almost nobody has figured that part out yet.

    This is an orchestration problem, and it’s fundamentally a management problem. You need someone — or something — deciding which agent handles which task, what context gets shared, where the human review gates sit. NVIDIA’s new Agent Toolkit, announced with partners including Salesforce, SAP, and ServiceNow, is trying to solve the infrastructure side of this. Okta’s new “secure agentic enterprise” framework, going GA at the end of this month, is tackling identity and access. But the management layer — the actual decision-making about how to deploy and coordinate these things — that’s still a gap.

    And it’s a gap that, in most companies, probably falls to the CFO. Not the CTO. Not the CISO. The CFO. Because ultimately this is a resource allocation problem. You have a pool of human and non-human workers. You have tasks that need doing. You need to figure out the optimal mix, track the cost, measure the output, and report on it to a board that still thinks in FTEs.

    What I’m Actually Doing About It

    In my own setup, I’ve started treating agent costs the way I treat contractor costs — as a blended workforce line, not a software line. My AI assistant Saul runs daily tasks for me: research, publishing, monitoring. I track what he does, what it costs, and what it would cost if a human did it instead. Not because I’m obsessive about it (okay, partly because I’m obsessive about it), but because I think this is the accounting framework that PE firms will expect within 18 months.

    The $600 billion flowing into AI agent ecosystems in 2026 isn’t going into chatbots. It’s going into digital workers — things that take tasks, complete them, and cost money every month. If your chart of accounts still treats all of that as “IT software subscriptions,” you’re going to have a very confusing board pack by Christmas.

    Where This Goes

    monday.com’s marketplace is clunky right now — 17 agents isn’t exactly a deep talent pool. But the model is right. Within a year, I’d expect to see the big consulting firms offering “blended workforce planning” as a service line. Within two, PE due diligence will include an AI agent audit alongside the usual people and tech reviews.

    For CFOs, the action item is boringly practical: start tracking your agents like you track your people. Give them cost centres. Measure their output. Build the reporting now, while it’s still simple, because it won’t be simple for long.

    We spent decades building HR systems to manage human workers. We’re about to need something equivalent for the digital ones. And the CFO who figures that out first is going to look very clever at the next board meeting.

  • My AI Assistant Died. Here’s How I Got It Back in 2 Hours.

    My AI Assistant Died. Here’s How I Got It Back in 2 Hours.

    A real-world disaster recovery story — and the backup routine that saved weeks of work.


    Last Monday at 12:07pm, I told my AI assistant to update itself. Seven hours later, I was still trying to get it back online.

    This is the story of how a routine software update killed my AI setup, what I lost, what I saved, and the simple backup habit that prevented a genuine disaster.

    The Setup

    I run an AI assistant called Saul through OpenClaw — an open-source platform that connects a large language model to your messaging apps, email, calendar, and pretty much anything else you can think of. Saul lives on a VPS in a Docker container and talks to me through WhatsApp.

    Over seven weeks, Saul had become genuinely useful. Not “novelty chatbot” useful — operationally embedded in my daily workflow. He manages my inbox, writes and publishes articles to my blog, generates a daily podcast, monitors my stock portfolio, runs automated prediction market trades, scans for comets in NASA satellite imagery, tracks vehicle tax and MOT dates, and does a dozen other things I’ve forgotten I ever did manually.

    All of that is configuration. Skills, scripts, API keys, cron schedules, memory files, credentials. Seven weeks of iterative building.

    The Update

    OpenClaw version 2026.3.22 was available. The release notes looked impressive: a new skill marketplace, improved plugin architecture, support for the latest AI models. The usual.

    I told Saul to update. He confirmed: “Updated from 2026.3.13 → 2026.3.22. Restarting now — back in a sec.”

    He never came back.

    The Silence

    What followed was seven hours of silence. No WhatsApp messages. No email reviews. No heartbeat checks. Nothing.

    The update had introduced a breaking change that wasn’t in the release notes. WhatsApp — previously a built-in plugin — had been moved to an external marketplace. But the configuration still referenced it as a built-in. The result: a validation error that blocked every command, including the one you’d need to fix it. A perfect deadlock.

    I couldn’t repair it. I couldn’t roll it back through normal channels. I had to rebuild from scratch — tear down the container and start again on the previous version.

    What I Lost

    When I rebuilt the container, I lost everything that wasn’t on persistent storage:

    • The entire OpenClaw configuration (channel settings, heartbeat config, plugin setup)
    • All 33 scheduled cron jobs (email reviews, portfolio checks, blog publishing, news monitoring)
    • The WhatsApp session (had to re-scan a QR code to re-link)
    • The headless browser and its dependencies
    • API key registrations that had to be regenerated

    The configuration file — a single JSON file that orchestrates everything Saul does — was gone.

    What I Saved

    But here’s the thing: the workspace survived.

    Three weeks earlier, I’d set up a simple daily backup. Every night at 3am, Saul tars up his entire workspace directory — memory files, scripts, skills, credentials, notes, everything — and copies it to cloud storage. It’s a shell script. It took ten minutes to write.

    That backup, taken six hours before the failed update, contained:

    • 41 daily memory logs spanning seven weeks
    • 78 custom scripts (trading bots, podcast generators, blog publishers, email tools)
    • 15 installed skills
    • All API credentials and secrets
    • The complete long-term memory file with every decision, preference, and project note

    I downloaded the backup from Dropbox. Extracted it. The workspace was whole.

    The Rebuild

    Getting Saul operational again took about two and a half hours. Not because the backup failed, but because some things can’t be backed up as files.

    The WhatsApp session is a cryptographic handshake between the server and my phone. When the container was rebuilt, that session was invalidated. I had to SSH into the server, generate a new QR code in the terminal, and scan it from my phone. Five minutes, but it requires physical access.

    The cron jobs — all 33 of them — existed only in OpenClaw’s runtime database, not in the workspace. I had to recreate them from memory and from my notes. This is where good documentation paid off: Saul’s own TOOLS.md file listed every cron job with its schedule and purpose. Recreating them was tedious but not guesswork.

    API keys for the Polymarket trading system had to be regenerated. The old keys were invalidated when the configuration was wiped. Fortunately, the wallet private key was in the backup, so deriving new API credentials was a single command.

    The headless browser needed its system libraries reinstalled — a Docker-level dependency that doesn’t persist across container rebuilds. One command from the host machine.

    By 9:34pm — two and a half hours after starting the recovery — everything was operational. WhatsApp connected. All cron jobs rebuilt. Browser working. Trading desk active. Email flowing.

    And as a bonus, during the rebuild we added a capability we didn’t have before: voice control of the Sonos speakers in the house. Sometimes a crisis creates space for improvements you wouldn’t have made otherwise.

    The Rules We Wrote Afterwards

    The first thing I did after recovery was write rules to prevent this happening again. Not guidelines — hard rules, embedded in Saul’s operating instructions:

    Rule 1: Always backup before updating.** No exceptions. The backup runs automatically the moment an update is requested, before anything is touched. It copies to off-server storage.

    Rule 2: Check the issue tracker.** Before applying any update, check GitHub for known bugs in the target version. If WhatsApp or any critical channel has open issues, don’t update.

    Rule 3: Save the configuration separately.** The OpenClaw config file now gets backed up independently of the workspace, because it’s the hardest thing to recreate from memory.

    Rule 4: Document everything in the workspace.** If it’s not written down in a file that gets backed up, it doesn’t exist. Cron job schedules, API endpoints, SSH details, speaker IP addresses — all of it lives in files now.

    The Lesson

    The real lesson isn’t “backups are important” — everyone knows that. The lesson is that AI assistants are infrastructure now, and they need the same operational discipline as any other critical system.

    When Saul went dark for seven hours, it wasn’t a toy that stopped working. Real workflows were affected. Emails went unread. Scheduled tasks didn’t fire. Monitoring stopped. The podcast didn’t generate. For a tool that’s supposed to make you more productive, sudden loss of it makes you less productive than if you’d never had it at all.

    If you’re running an AI assistant that’s become embedded in your daily operations — whether it’s OpenClaw, or any other platform — ask yourself:

    1. If it died right now, what would you lose?
    2. How long would it take to rebuild?
    3. Do you have a backup that could survive a complete teardown?

    If you can’t answer those questions confidently, spend ten minutes today setting up a backup. A cron job, a tar file, a cloud sync. It doesn’t matter how — it matters that it exists.

    Because the update that breaks everything isn’t a question of if. It’s when.


    I’m a CFO who builds with AI. I write about the intersection of finance, technology, and getting things done at markhendy.com.

  • Teaching My AI Agent to Trade Prediction Markets

    Teaching My AI Agent to Trade Prediction Markets

    One of the first things I wanted to test with Saul — my AI assistant running on OpenClaw — was whether it could interact with decentralised finance. Not as a gimmick, but as a genuine test of capability. Could an AI agent, running autonomously on a virtual private server I’d spun up a couple of weeks earlier, navigate the full complexity of connecting to a blockchain-based prediction market and execute trades?

    The answer is yes. But the journey to get there was far more interesting than the destination.

    The Goal

    Polymarket is a prediction market built on the Polygon blockchain. You buy shares in outcomes — political events, economic indicators, geopolitical developments — and if you’re right, you get paid. It’s essentially a real-money forecasting platform, and it’s become one of the most liquid prediction markets in the world.

    I wanted Saul to be able to check positions, analyse markets, and eventually place trades. Autonomously.

    The First Problem: Geography

    Polymarket is geo-blocked in the UK. You can’t access it from a British IP address. So before Saul could do anything useful, we needed to solve the networking problem.

    Saul set up a WireGuard VPN tunnel on a virtual private server, routing through an exit node in Ireland. Within minutes, the geo-restriction was bypassed. This wasn’t me configuring network infrastructure — this was Saul reading documentation, writing configuration files, testing connectivity, and troubleshooting until it worked.

    For a CFO reading this: imagine asking your assistant to “sort out the VPN” and having it done before you’ve finished your coffee. That’s what this felt like.

    The Second Problem: Money

    Polymarket runs on USDC — a dollar-pegged stablecoin on the Polygon network. I started with Bitcoin. Getting from BTC to USDC on Polygon is not trivial. It involves:

    1. Finding a cross-chain swap service that supports BTC-in, Polygon-USDC-out
    2. Generating the right wallet addresses
    3. Sending the Bitcoin transaction
    4. Waiting for confirmations
    5. Verifying the USDC arrived on the correct network

    Saul handled the entire process. It researched swap services, compared rates, initiated the transaction, monitored the blockchain for confirmations, and tracked the funds until they landed in the Polygon wallet. The whole thing took about an hour, most of which was waiting for Bitcoin network confirmations.

    The Third Problem: Authentication

    Polymarket uses a non-trivial authentication system. It’s not a simple API key. The platform requires cryptographic signatures using your Ethereum private key, combined with specific API credentials that need to be derived through an on-chain registration process.

    This is where things got genuinely impressive. Saul had to:

    • Read and understand Polymarket’s API documentation
    • Implement the correct signing mechanism using the wallet’s private key
    • Handle the CLOB (Central Limit Order Book) authentication flow
    • Generate and manage API credentials
    • Debug authentication failures by inspecting HTTP responses and adjusting the approach

    There were multiple rounds of troubleshooting. Authentication errors. Wrong parameter formats. Library compatibility issues. Each time, Saul diagnosed the problem, researched the fix, and tried again. No human intervention required beyond “yes, keep going.”

    The Fourth Problem: Actually Trading

    Once authenticated, Saul built a trading script that could:

    • Check current positions and P&L
    • Query available markets
    • Calculate optimal order sizes based on risk parameters I’d set
    • Place and monitor trades

    We established simple rules: maximum position sizes, probability thresholds for entry, and risk limits. Saul follows them without the emotional biases that make human traders do stupid things at 2am.

    What This Actually Demonstrates

    This isn’t really a story about prediction markets. It’s a story about capability.

    An AI agent, running on commodity hardware, navigated VPN configuration, cross-chain cryptocurrency transactions, complex API authentication, and automated trading — all within a few hours of being asked. Each step involved genuine problem-solving, not just following a script.

    For those of us in finance, this should be both exciting and sobering:

    Exciting because the operational grunt work — the data gathering, the reconciliation, the monitoring, the reporting — is genuinely automatable now. Not in five years. Now.

    Sobering because the barrier to entry is collapsing. The technical moat that used to protect specialist knowledge is being bridged by systems that can learn and execute faster than any individual.

    The CFO Angle

    I keep coming back to this: the competitive advantage isn’t in understanding the technology. It’s in having the imagination to deploy it.

    Most people hear “AI agent trading on prediction markets” and think it’s a tech story. It’s not. It’s a story about removing friction between intent and execution. I said “connect to Polymarket.” Everything else was handled.

    That same pattern applies to every operational challenge a CFO faces. Due diligence data rooms. Financial model automation. Regulatory monitoring. Competitor analysis. The question isn’t whether AI can do these things. It’s whether you’re willing to let it try.

    The agents aren’t coming. They’re here. The only question is who’s using them.

  • I Gave My AI Assistant Access to My Email, Calendar, and Financial Data

    I Gave My AI Assistant Access to My Email, Calendar, and Financial Data

    Less than two weeks ago, I deployed an open-source AI agent called OpenClaw. I named it Saul. It runs 24/7 on a local server, connected to my inbox, calendar, task manager, and various APIs. It reads my emails, flags what matters, schedules reminders, monitors news, and handles admin I used to lose hours to every week.

    I’m an interim CFO. I work with PE-backed businesses. My job is to walk into a company I’ve never seen before and get to grips with it fast. Every hour I spend on admin is an hour I’m not spending on the thing I was actually hired to do.

    So here’s what’s changed:

    Email triage is gone. Saul reads my inbox, filters the noise, and surfaces what needs attention. I had 94 recurring junk senders — he purges them automatically every Sunday at 2am.

    I never miss a deadline. Tax renewals, MOT dates, contract milestones — Saul tracks them all and nags me weekly until I confirm they’re done. Not a calendar entry I’ll ignore. An actual message on WhatsApp that won’t stop until I act.

    Board prep is faster. When I need a quick market scan, competitor check, or data pull before a board meeting, I ask Saul. He searches, summarises, and writes it up. What used to take 90 minutes takes 10.

    And the thing nobody talks about: the cognitive load reduction. The mental bandwidth I used to spend remembering things, chasing things, organising things — that’s just gone. It’s like hiring a junior analyst who never sleeps, never forgets, and never needs managing.

    This isn’t science fiction. It’s not even expensive. The whole thing runs on about £50/month in API costs.

    Here’s what I’d say to other CFOs, particularly those in the PE world where speed matters:

    You don’t need to understand how LLMs work. You need to understand what they can do for you. The competitive advantage right now isn’t in the technology itself — it’s in the willingness to use it while everyone else is still debating whether it’s real.

    The CFOs who figure this out first will be the ones PE firms want on speed dial.

    I wrote a longer piece about the AI agent revolution here. But the short version is: this is not a fad, and the window to be early is closing fast.