The Cron Job Inception Strategy for Self-Expanding AI Agents

The most capable AI agent you can build is one that finds new work to do while it is already running. A static schedule that repeats the same tasks at the same times is reliable and predictable, and it will never surface a signal you did not already know to look for. This piece is about the design that breaks that ceiling: an agent whose scheduled jobs are allowed to write new scheduled jobs based on what they discover, with the whole system governed by four elements that must all be present or the approach becomes dangerous rather than useful. I am Madhuranjan Kumar, and I want to walk through the playbook step by step, because the spawning mechanism itself is almost secondary to the guardrails that make it work safely.

Write the core goal in one precise sentence before building anything else

Autonomy without direction produces noise. An agent that can create new tasks for itself but has no precise objective to evaluate them against will spawn work in every direction it encounters something that looks potentially interesting. Within a week the schedule is full of activity and empty of value, because no individual task was ever tested against a clear standard before it was created.

The core goal is a single sentence written in concrete, evaluatable terms before any code is written, before any schedule is configured, and before any integration is wired. Not grow the business, which is too broad to produce a yes or no decision on any given discovery. Not increase engagement, which is an outcome metric rather than a directional target. Something like: book more seasonal service jobs from homeowners in our local service area. That sentence is specific enough that any proposed new task can be evaluated against it and returned a genuine yes or no.

The core goal also sets the scope boundary for the entire system. Anything a spawned job proposes that does not serve that goal is rejected, not added to the consideration pile, not deferred to a later session, just rejected. That boundary is what keeps the schedule from drifting over time into a mix of vaguely interesting tasks that collectively serve nothing in particular. Write the goal first. Make it one sentence. Test it by asking whether any given proposed action is clearly yes, clearly no, or unclear. If too many answers are unclear, the goal is not specific enough yet.

Store the spawn rules in the file the agent reads at the start of every single run

Spawn rules are the criteria that govern when a job is allowed to create a new job. They answer the question: under what conditions is spawning permitted, and what must be true about a proposed new job before it can be created? Without written rules, the agent fills in its own judgment, and that judgment drifts in ways that are hard to catch and hard to correct.

The spawn rules belong in the agent's primary instruction file, the one it reads at the beginning of every run. Not in a separate document it might or might not consult. Not in a setup file it reads only once when first configured. In the file that loads on every single run, so the rules are active every time the agent makes a decision rather than only present when you were the one who set it up.

The three conditions that a proposed spawn must satisfy before it is allowed are: the discovery must be genuinely novel, meaning it is not information the base schedule already surfaces routinely. It must be relevant to a specific person or audience who would clearly care about it, meaning it is not just interesting in the abstract. And it must add real value rather than generating additional activity for its own sake, meaning the action it leads to is worth taking. All three conditions must pass. If any one fails, no spawn is created. That triple condition is the filter that keeps each new job meaningful rather than marginal, and it must be written out explicitly in the instruction file rather than described informally in notes the agent never reads.

Enforce the spawn cap in the execution environment, not just in the instructions

An instruction that tells the agent to limit itself to two new spawns per session will be followed in normal circumstances. Edge cases, novel situations, and accumulated context that makes an additional spawn seem clearly justified are the circumstances where instruction-following becomes less reliable. An enforcement mechanism built into the execution environment rather than expressed only in the instructions is meaningfully more robust.

The implementation is simple: a counter that increments each time a new job is scheduled, checked before any spawn call is executed, and that blocks the spawn entirely if the count has reached the limit. The agent does not make the decision about whether it is over the limit. The code makes that decision for it. That is a fundamentally different kind of constraint than one that exists only in the instruction text.

The same logic applies to ensuring spawned jobs self-delete after running exactly once. The self-delete should be part of the job's own code rather than an instruction to the agent to remember to delete itself. Code that runs unconditionally at the end of a job is more reliable than an agent instruction that can be missed or deprioritized if the job encounters an unusual situation. Enforce both the cap and the self-delete in the execution layer so the schedule stays bounded regardless of what the agent decides within any individual run.

Design every spawned job to delete its own schedule entry after running exactly once

A spawned job that does not self-delete becomes a recurring job. Two sessions in, the schedule has two extra jobs running repeatedly. After ten sessions it has up to twenty additional jobs, some of which were created in response to signals that are no longer relevant, and all of which are consuming agent time and attention that the original design never budgeted for. The schedule becomes unmanageable before anyone has noticed it happened.

The solution is architectural rather than instructional. Every spawned job includes its own cleanup step as the final action in its execution sequence. The job runs its task, logs the outcome, executes the three-question evaluation, and then deletes its own cron entry before closing out. That last step is not optional and is not subject to the agent's judgment about whether it applies. It runs every time, unconditionally.

The design implication is that spawned jobs are fundamentally different from base jobs. Base jobs are recurring by definition. Spawned jobs are single-run by design. If a spawned job surfaces something worth monitoring on an ongoing basis, the evaluation step produces a recommendation for the human reviewing the log to consider adding it as a new base job. That decision belongs to a person, not to the agent. The agent surfaces the signal. The person decides whether it warrants a permanent addition to the schedule. That separation of responsibilities is what keeps the base schedule coherent over time.

Build the three-question evaluation as the mandatory final action of every run

The evaluation step is the brain of the entire system. Without it, the agent completes each run without ever articulating what it found, whether it was relevant, or whether it produced a candidate for a new task. The log fills with activity records and the human reviewing it has to do all the synthesis work manually to decide whether anything that happened during the run warrants a follow-up. That is a significant burden on the reviewer and a missed opportunity for the agent to do the thinking it is capable of.

The three questions the evaluation must answer are: Did I find something genuinely novel during this run, something that was not already covered by the base schedule? Is it relevant to a specific person or audience who would clearly care about it? Should it become a new scheduled task?

All three questions must be answered explicitly in the evaluation output, not implied or inferred. If the answer to all three is yes, the agent spawns one new job within the session cap. If any answer is no, the agent logs the evaluation result with an explanation and closes out the run without spawning. That logged explanation is the audit trail that lets a human reviewer understand why the agent made the decisions it did, which is what makes the system inspectable and correctable over time.

Making this step mandatory means building it into the job structure rather than including it as a prompt instruction the agent might skip if the run is long or the context is full. The evaluation executes as the last step of every run, including spawned jobs, regardless of what happened during the session. The evaluation either produces a spawn or it does not. Either outcome is logged. Nothing closes without it.

Test the loop at low stakes and read what the agent proposes before trusting real signals

The first test of the system should be pointed at a data source where a missed discovery or an imperfect proposal has no real cost. A technology news aggregator, a publicly available job board for a category you are curious about, a community forum where the business has no existing presence: sources where the agent can practice the full loop, read the instructions, scan the content, evaluate against the goal, and propose a spawn if the conditions are met, without any of its proposals going anywhere before a person reviews them.

Running this low-stakes test for a week produces a pattern of what the agent actually surfaces versus what the goal suggests it should surface. If the proposals are consistently misaligned with the stated goal, the goal needs to be more specific. If the agent is spawning on marginal signals because the novelty condition is not strict enough, the spawn rules need tightening. If the evaluation explanations are thin and unconvincing, the evaluation prompt needs more structure. Every one of those adjustments is far cheaper to discover in a low-stakes test than after the system is connected to real customer communications, real prospect data, or real public channels where off-brand messages have consequences.

Read every proposal the agent makes during the test period, even the ones that fail the evaluation and produce no spawn. The explanations for rejected spawns are often more informative than the accepted ones, because they reveal how the agent is interpreting the goal and the rules in situations where the right answer is no. If the rejections are for the wrong reasons, the rules need revision. If the acceptances are for the wrong reasons, the goal needs revision. Both corrections are easy to make during a low-stakes test and much harder to make after the system has been running in a live environment for two months.

Here is the concrete shape this takes for a landscaping company whose stated core goal is: book more seasonal service jobs from homeowners in our local service area.

The base scheduled job runs each morning. It scans three sources: new property listings in the ZIP codes the company serves, community posts in local neighborhood groups asking for lawn care help or yard cleanup, and seasonal weather signals that indicate when service demand is about to increase. The job reads the goal, checks each signal against the three evaluation conditions, and either proposes a spawn or logs that nothing warrant one.

On a Monday when the scan surfaces fifteen new home sale records on the same street and an additional eight on an adjacent block, all within the last 30 days, the novelty condition passes, the relevance condition passes, and the value condition passes. The agent spawns one follow-up job: draft a friendly neighborhood introduction offer addressed to that block, showing available seasonal services and a local reference, queued for owner review before anything goes out. That job runs the same afternoon and produces a draft. The owner reads it, approves a lightly edited version, and the outreach goes out by end of day.

If that follow-up job, while executing, also discovers that the same neighborhood has a community cleanup event posted for the following Saturday, it evaluates whether the conditions pass for a second spawn: propose a sponsorship inquiry or a free demo offer for the event. The conditions pass. Within the two-spawn cap for the session, a second job is created. The owner receives two proposed actions that morning instead of one, both tied directly to the stated goal, both requiring approval before anything leaves the building.

Before the system was running, the owner found roughly three useful signals per week through manual monitoring, typically during a twenty-minute scan of community groups and listings on Sunday evenings. By week four of the system running, the agent is surfacing nine proposals per week. By week twelve it is surfacing eighteen, because the evaluation logic has been refined through six weeks of logged proposals and the spawn rules are sharper than they were at the start. The owner's time investment has not increased. The discovery volume has grown by a factor of six. Three of those eighteen weekly proposals typically convert to booked work, compared to one per week from the manual monitoring process. None of that improvement required the owner to spend more time monitoring. It required designing the four elements correctly at the start and committing one week to low-stakes testing before connecting the system to real outreach channels.