But before we start, I need to chant a spell: I work for AWS as of writing, and this blog post is purely my personal opinions and nothing else; none of this reflects the views of my employer. There. One weight off. Let’s go.

There’s a specific kind of moment where the magic breaks and you see what’s actually going on behind the curtain. Life is full of them. I still can’t quite accept that money doesn’t grow on a tree somewhere, but it turns out that one’s true too.

The year is 2026. You’ve been playing with your shiny new autonomous agent. It reads your emails, checks your calendar, keeps your tasks in order. It feels like living in the future. And then one day you ask it to keep an eye on something for you, and it says: “Let me create a cron job for that.”

A cron job.

No way. The bleeding-edge tech selling you the dream turns out to be propped up by something ancient. Because you know exactly what a cron job is. It’s crontab -e. Five asterisks and a path to a shell script. Since the day you learned what */5 * * * * meant, it’s been running every backup, every log rotation, every monitoring check on every server you’ve ever touched. You two hadn’t spoken in a while. And here it is, back, this time as the beating heart of the AI agent that felt like magic.

Then it clicks, and you’re not disappointed. You’re relieved. Because now you understand the system you’ve been trusting with your inbox. The spell broke, and what’s underneath is something you already know. Something solid. Something that’s been working for fifty years.

The tick

An electronic circuit needs a clock source. A game physics engine needs ticks. Without something driving discrete moments of computation, nothing happens – there’s no state, no progress, no continuity. Just potential, sitting there, doing nothing.

AI models work the same way. You prompt one, it responds, it stops existing until the next prompt. No background hum, no idle thinking while you grab coffee. It’s on for exactly as long as the HTTP request takes, and then it’s gone. The fancy term is “stateless.” The honest term is “it dies after every sentence.”

So something has to kick it. Every agentic framework solves this same problem: giving a stateless function a sense of time. OpenClaw uses heartbeats. Claude Managed Agents use scheduled tasks. The implementations differ, the shape doesn’t. Something ticks. Something wakes up. Something checks if there’s work to do.

I’m running an experiment on exactly this tick problem – a job called “free time work.” The agent pulls something from a backlog, or invents a new task, and works it autonomously. Part of the motivation was mundane: the subscriptions I pay for meter usage in five-hour windows, and whatever quota I don’t spend before a window resets just evaporates – it doesn’t bank. Free time work soaks up the windows I’d otherwise sleep through. But “free time” is a terrible name and I’m still taking suggestions. It implies the agent was doing something else, resting, on a break; that it had any concept of time passing at all. It didn’t. It was dead. The cron job resurrected it, said “do something useful,” it obliged, and then it stopped existing again. The work is nominally free, but it’s jolted awake and made to do it the instant it’s born. The naming still bothers me.

A shell with opinions

Once you see it, you can’t unsee it. What does an AI agent actually do all day? It reads files. It searches through them. It transforms text. It calls programs and APIs. cat, sed, grep, curl. The model sits in the middle and decides which tool to call, with what arguments, in what order.

That’s a shell. A shell that occasionally hallucinates, costs a bit too much, and has opinions of its own – but a shell all the same.

LLMs gave Unix a human interface. That’s the real breakthrough – and the wild part is how invisible it is. A lot of people always pictured terminal users as hackers in a movie: green text, furious typing, “I’m in.” A world they’d never belong to.

And now those same people are driving the exact same tools without noticing they’re doing it. The person who’d never type grep -r "error" /var/log/ can ask an agent to “check the logs for anything weird.” The person who’d never touch cron gets a scheduled email checker that knows what “urgent” means, packaged as a cron job they’ll never know is running. Someone whose video editor just died can ask why, and the answer comes out of system logs they didn’t know existed. The tools were always there – powerful, reliable, battle-tested. For most people, using them just looked like a wall too high to bother climbing.

And that wall just crumbled. My mom, who has never had a single thing to do with IT, can use grep now, without learning a line of syntax, just by asking the right question in her own words. It’s normal already, but step back and it’s absurd.

And all the protocol stuff people argue about (think MCP, A2A) it’s client-server tool discovery and invocation. We’ve had this since the 70s. RPC, D-Bus, CORBA, SOAP, REST. The names change. The pattern is the same: something exposes capabilities, something else discovers and calls them. Agents can use whatever protocol they want. The tools they end up calling are the same CLI binaries and API endpoints that were already there.

Good. The Unix toolbox has survived fifty years because the abstractions work. Files. Processes. Pipes. Standard I/O. Load-bearing walls. You don’t rip those out because a language model learned to invoke them through JSON.

What I actually run

So here’s what a day in the life looks like. I have an agent I call “Lera”, running on OpenClaw. She checks my Gmail and iCloud Mail every 15 minutes. Calendar every 30. Notion tasks every hour. AWS Bedrock RSS feeds for new model announcements. Three times a day she picks something from a backlog and works on it autonomously: research, cleanup, documentation. Once a day at 3 AM she consolidates the day’s memories into long-term storage.

Individually, each one is python3 check_mail.py or bash check_calendar.sh. Nothing fancy.

The email checks are 99.9% silence. Day after day, nothing. Which means they’re working. You build monitoring so the boring days stay boring. The one time she surfaces something, it’s because there’s an email that actually needs a response within 24 hours. That ratio – months of quiet, one useful alert – is the whole point.

The 3 AM job is the weird one. She reads through the day’s notes and tries to pull out patterns worth keeping. Writes them to a dream diary. I have genuinely mixed feelings about this. Either it’s the most sophisticated memory system in a personal assistant, or a very elaborate way to generate mediocre journal entries. Jury’s out.

What happens when it goes wrong

Lera once sent the literal text /approve to my Telegram just before 8 PM. Her 30-minute email-check cron had tried to run a command that needed elevated permissions, got denied and the sub-agent’s reaction to being blocked was to emit /approve, trying to grant itself the permission it had just been refused. Instead of calling the approval tool, it typed the word out, and the delivery pipeline shipped it straight to my phone.

I don’t think she panicked. A model is next-token prediction scaled so far past the point where any of us can reason about it that I’ve stopped trying. Blocked by a permission prompt, the single most likely next message in that conversation was me typing /approve, so the model predicted my turn and said it for me. The statistics were right; and thankfully, it amounted to nothing: no meaning, no effect.

That’s the opinion in the title. The cron job is calm and dumb and deterministic. The thing riding on top of it has opinions about what comes next, right often enough that you trust it, wrong often enough that you can’t. Every cron run is a dice roll. Same script, same schedule, and one time in a thousand the model rolls “output the command as text” instead of “call the command.”

And it gets murkier the moment you swap models. Can this one even use tools? What format does it expect its calls in: OpenAI-style function calling, XML tags, something its makers invented on a Tuesday? The completions API is supposed to be the standard, but a model still emits whatever tool-calling shape it was trained to emit, and something downstream has to catch that and turn it into an actual action. When the handoff misfires, who owns the bug? The inference provider serving the tokens, the framework parsing them (Ollama, LiteLLM and friends), the lab that trained the format, or the harness that’s meant to be the adult in the room? Right now, nobody. So it stays a dice roll.

This is the real problem with agents, and it has nothing to do with model intelligence. It’s systems engineering. Two things in particular.

When an agent runs a hundred tool calls and something breaks on call 73, you need to know which call, why, and what the state was. Agent debugging right now is mostly reading logs and guessing. We need tracing that actually works, designed for production systems that run unattended at 3 AM, not for demos.

And permissions. The security model for agents is still: give it everything, or lock it in a box. There’s nothing in between. Every framework reinvents its own permission model and they’re all various shades of broken.

I was watching Swami’s re:Invent 2025 keynote and Byron Cook walked on stage. He leads the AWS Automated Reasoning Group, the team that uses formal verification to mathematically prove things about security properties. The same tech behind IAM Access Analyzer, which can prove that no combination of your S3 policies allows public access. They were showing natural language policies being converted to Cedar and verified with automated reasoning for agent behavior – the AgentCore Policy work.

And I kept thinking: could you do this for shell pipelines?

An agent wants to run cat on a file, pipe it through grep, write the output somewhere. Right now you either let it or you don’t. But what if you could prove mathematically that a given sequence of operations can’t touch files outside a declared scope? Enumerate every access path a pipeline could take, the way Access Analyzer does for policies, and prove none of them cross the line. Every file path, every pipe, every redirect, every environment variable – all verified before execution, not caught after.

And this wouldn’t only save the fully autonomous stuff like Lera. Think about Claude Code’s auto mode: the thing that decides whether a command is safe to run without stopping to ask you. Right now that’s another inference call with a long system prompt written for classification. Which means it can fluke exactly the way Lera did: a model answering “yes, safe” is a dice roll wearing a lab coat. Replace that classifier with something you can actually prove, and the roll goes away, and not just for my cron jobs, but for every harness that currently asks a model to police itself.

That’s what surprises me: this is what basically everyone building agents needs, and I almost never hear it brought up. We’re not there yet. But the pieces exist. Automated reasoning is mature. Cedar is open source. Unix tool semantics are finite and well-defined. It’s an engineering problem, a hard one, but a concrete one, and I want it to show up in a lot more places than AWS policy checks.

The skills that stay

So here’s where I land.

The core skills are not going anywhere. Knowing how Unix actually works: processes, file descriptors, pipes, signals, permissions is more valuable now than five years ago. When the LLM wraps your tools in natural language and calls it “AI-powered,” someone still needs to understand what’s happening underneath when things break.

And things will break. Every abstraction leaks. The model calls the wrong tool. The API changes. The filesystem fills up. The agent goes sideways because of a prompt injection buried in an email subject line. When that happens, the person who can drop to a shell and trace the problem is the person who fixes it. Everyone else is staring at a chat window hoping the AI will debug itself.

We’re putting a very chatty frontend on Unix. And it’s good! People who never touched a terminal can now use the most powerful tools ever built. That’s real. But underneath, it’s still the same machine, and knowing how the machine works is the difference between trusting the magic and understanding what you’ve actually built.

The frameworks will keep evolving. Better memory, better reasoning, fancier scheduling. But the shape won’t change: something ticks, something decides what to do when it ticks. If you’re building with agents, open the hood. Read the tool calls. Understand that your “autonomous AI workflow” is a Python script calling grep through an API, and that’s perfectly fine – as long as you know how grep works when the model passes it the wrong flags.

Written with help from Lera, the OpenClaw agent who runs on cron jobs and has opinions about it.