RICK, MORTY, SUMMER: A small agent mesh that lives on cron jobs
A system note on how I split three agents across machines, schedule recurring work, and keep automation visible instead of magical.
At some point, setting up automation is not enough.
Scripts, cron jobs, agent prompts, morning briefs, daily summaries... At first each one looks like a small convenience. Then the number grows. Eventually you no longer have separate tools. You have a small operating system breathing inside the house, partly independent from you.
That point is useful, but also a little dangerous. Working systems create calm. They also create blindness. If something sends you a report every morning, you start assuming it is useful. If an agent quietly finishes a task, you assume it finished the right one. If an automation produces no error, you assume it is healthy.
Most of the danger is not in the error message. It starts somewhere quieter: is the system still serving my intention, or am I slowly adapting to the rhythm it produces?
This post is my attempt to answer that. I have a small three-agent machine network split into RICK, MORTY, and SUMMER. I wanted to explain how it works, which agent owns which kind of work, and what cron jobs do inside that structure in a way other people can reuse.
I am not going to focus on raw error logs. I care more about the working shape. The question for me is simple: how do I make recurring work in my life and projects more visible, more measured, and safer?
The Turkish original is here: RICK, MORTY, SUMMER: Cron Job'larla Yaşayan Küçük Bir Ajan Ağı.
Three agents, three roles
· · ·
RICK MORTY SUMMER
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ RICK │ │ MORTY │ │ SUMMER │
│ │◆ · · │· · · │
│ plan │ │ ship │ │ report │
└──────────────┘ └──────────────┘ └──────────────┘
· ·
same system, separated responsibility
In my setup, the agents are not three copies of the same thing. Each one carries a different weight.
RICK is strategy and coordination. Planning, writing, decisions, prioritization, RUNE flows, the work at the head of the table. RICK's job is not to do everything. It is to understand what should be done, what should not be done, and when the available information is enough.
MORTY is execution. Bots, automations, repeated tasks, practical finishing work. If something needs to be completed, it usually belongs to MORTY.
SUMMER is observation and reporting. It watches changes during the day, summarizes them, and keeps the pulse of the system. It does not always need to act. Sometimes a good observation is more valuable than a rushed intervention.
This separation looks small, but it matters. Naming agents is not a cute decoration. It draws responsibility boundaries. RICK should think. MORTY should finish. SUMMER should watch. If all three try to do everything at once, the system does not become stronger. It becomes blurry.
A cron job is really a rhythm
· · ·
CRON RHYTHM
· · ·
· ·
08:00 brief · · 13:00 delta
· · · ·
· ·
· ◆ · · · · ◆ · · · ·
· ·
· · · ·
weekly review · · 17:00 check
· ·
· · ·
A cron job is simply a scheduled task. A command, report, or agent assignment that runs automatically at specific times.
But I do not see it only as a technical mechanism. Cron jobs are the rhythm of the system. Which report arrives in the morning? What gets checked at midday? Which project comes back to the table once a week? Each task is small on its own, but together they create an operating cadence.
In my setup, some jobs produce a morning brief. Some summarize what changed during the day. Some run weekly project checks. Some make me review the decisions that agents made earlier.
The goal is not to automate everything. It is the opposite: keep the automation visible.
When automation becomes silent, it stops being magical and starts becoming dangerous. Is the job still running? Is it producing noise? Is it doing something on its own that should have waited for my approval? I can only answer those questions if the system reports on itself regularly.
How to build a small agent mesh
· · ·
SMALL AGENT MESH SETUP
┌────────┐ ┌────────┐ ·┌────────┐
│ 1 │ ┌────────┐ │ 3 │ ┌────────┐ │ 5 │
│main bot│◆ │ 2 │ │schedule│· │ 4 │ │approval│
└────────┘ │split wo│· └────────┘ │one outp│· └────────┘
└────────┘ └────────┘
· ·
one computer is enough
My current structure is spread across three machines, but the idea works at a smaller scale too. You can build a similar rhythm on one computer.
The basic pieces are:
- Pick a main agent for planning and decisions.
- Split recurring work into separate tasks: morning summary, project check, research scan, maintenance note.
- Schedule those tasks with cron or another scheduler.
- Send the outputs to one place: terminal, file, Telegram, email, or dashboard.
- Do not automate risky actions. Ask the system to report first.
The fifth point is the critical one. The power of agents is not only that they can write, generate code, or run commands. Their power also depends on knowing where to stop.
The rule I keep trying to enforce in my own system is this: read first, report next, ask if needed.
Restarting services, merging branches, sending external messages, touching payments or credentials, those belong to another class. They are not the normal breathing of automation. They are interventions that need explicit approval.
Why reports matter
· · ·
REPORTS / SINGLE VISIBILITY POINT
┌────────────┐ ┌────────────┐ ┌────────────┐
│ RICK │ │ MORTY │ │ SUMMER │
│ · │ │ │ │ · │
└────────────┘ └────────────┘ └────────────┘
◆ · · · ◆
· · · ·
· ◆ · · · ◆ ·
· · · ·
┌──────────────────────┐ ·
│ inbox / dashboard │
│ system explains itself
└──────────────────────┘
It is hard to keep everything in one human head. Especially when there are multiple projects, multiple agents, multiple machines, and normal daily work happening at the same time.
That is why I like reports. They do not need to be brilliant. Sometimes a boring "nothing changed today" report is more valuable than a flashy AI output. It means the system knows how to wait without lying.
What SUMMER does feels a little like a watch log. What is happening in the morning? What changed at noon? What should I look at before the day ends? What is still open at night?
MORTY sits more on the finishing side. RICK tries to interpret the incoming signals. When the three rhythms come together, automation stops being a thing that merely runs in the background. It becomes a system I can maintain.
What makes a good system for me
· · ·
A GOOD SYSTEM SHOWS ITSELF
1. what did it do? ████████
· ·
2. where silent? ░░░░░░░░
3. who did it? ░░░░░░░░
· ·
4. needs approval? ░░░░░░░░
not just active; readable
A good system is not only a system that does work.
A good system can:
- show what it did,
- make it clear when it went silent,
- separate which agent did which job,
- wait for approval on critical interventions,
- attach recurring work to rhythm instead of memory.
That is why cron jobs feel like small internal organs. Normally you do not see them. But every now and then, you need an ultrasound. Otherwise the thing you think is working may only be producing noise, and the thing you thought had gone silent may be saving you in the background.
If you want to build your own version
· · ·
START SMALL
┌────────────────┐ ┌────────────────┐
│ morning brief │ │ weekly check │
│ │◆ · · · · ◆ · · · │
│ │ │ │
└────────────────┘ └────────────────┘
┌────────────────────┐ ·
│ rhythm grows │
│ │
└────────────────────┘
rhythm first, scale later
The names and machines I use are personal. The model is general:
- Set aside one agent for planning.
- Set aside one agent for execution.
- Set aside one agent for observation and reporting.
- Schedule recurring work.
- Collect reports in one place.
- Do not automate risky actions; put them behind approval.
- Ask the system to explain itself from time to time.
You do not need three machines at the beginning. You can define three roles on one computer. The first version can be as small as a morning summary and a weekly project check.
The important thing is this: build the rhythm before you scale the automation.
My RICK, MORTY, SUMMER setup is an experiment in that direction. It is not perfect. That is the honest part of building systems. You are not trying to create a flawless structure. You are trying to create one that shows itself better, is easier to maintain, and creates fewer surprises.
Once you set something up properly, you do not only preserve the output. You preserve the way of producing it. I think this is where working with agents starts to become genuinely powerful.
A system note on how I split three agents across machines, schedule recurring work, and keep automation visible instead of magical.