Tick-Based Execution: Scheduled Agent Activity

The Tick Loop

A tick-based agent follows a repeating cycle: wake, observe, decide, act, sleep. On each tick, the agent reads the current state of its environment from whatever sources are relevant: log files, database queries, API endpoints, metric dashboards, message queues, or file system contents. It evaluates what it observes against a set of conditions or goals. If conditions require action, the agent acts. If everything looks normal, the agent does nothing. Then it sleeps until the next tick.

The simplicity of this cycle is its primary advantage. There is no event infrastructure to set up, no message routing to configure, no queue to manage. A cron job, a system timer, or a simple sleep loop in a long-running process is sufficient to implement the scheduling. The agent's logic is a single function that runs periodically, making it easy to understand, test, and debug.

Each tick is also naturally isolated. The agent starts each tick with a fresh observation of the current state rather than relying on state accumulated from previous ticks. This means that a bug in one tick's processing does not corrupt subsequent ticks. If the agent makes an incorrect decision on one tick, the next tick starts clean and has the opportunity to observe the corrected state and make a better decision. This self-healing property makes tick-based agents more forgiving of errors than continuously running agents whose state accumulates over time.

The limitation of the tick model is latency. Events that happen between ticks are not detected until the next tick. With a five-minute tick interval, an event could go undetected for up to five minutes. For many monitoring and maintenance tasks, this latency is acceptable. For real-time response requirements, event-driven architecture is more appropriate. The choice between tick-based and event-driven execution often comes down to whether the acceptable response time is measured in seconds or minutes.

Choosing the Tick Interval

The tick interval is the most important configuration parameter in a tick-based system. It determines the maximum detection latency, the resource consumption, and the cost of running the agent.

Short intervals (seconds to one minute) provide rapid detection and response but consume more resources. An agent that ticks every 10 seconds makes an LLM call every 10 seconds, even when there is nothing to do. At current API pricing, this adds up quickly. Short intervals are appropriate for high-value monitoring tasks where the cost of delayed detection exceeds the cost of frequent polling: production system health checks, security monitoring, real-time data pipeline validation.

Medium intervals (one to fifteen minutes) balance responsiveness with cost efficiency. Most monitoring and maintenance tasks work well at this cadence. Checking for new support tickets every five minutes, reviewing database replication status every ten minutes, or scanning for stale resources every fifteen minutes provides timely detection without excessive resource consumption. This range covers the majority of production tick-based agent deployments.

Long intervals (hourly to daily) suit tasks where freshness is not critical. Generating daily summary reports, performing weekly code quality audits, or running monthly compliance checks are all tasks where the value of the output does not change meaningfully between ticks. Long intervals minimize cost and system load while still ensuring the task runs regularly.

The interval should be informed by two factors: the maximum acceptable detection latency (how long can an event go unnoticed before consequences become significant) and the cost of each tick (how much does it cost to run the agent's observation and decision logic). If the cost per tick is very low (a few database queries with no LLM call needed when nothing is happening), short intervals are affordable. If each tick requires an LLM call regardless of whether action is needed, longer intervals or a smarter observation strategy becomes important.

Efficient Tick Processing

Not every tick requires the full power of a language model. A well-designed tick-based agent uses a tiered evaluation approach that minimizes cost by using the cheapest sufficient method at each stage.

Fast pre-check. Before invoking the LLM, the agent performs lightweight programmatic checks. Has the database queue grown beyond a threshold? Are there new files in the monitored directory? Has the error count metric increased since the last tick? These checks are essentially free, running as simple comparisons or database queries. If all pre-checks pass, the tick completes without an LLM call.

Triage call. If pre-checks detect something worth investigating, the agent makes a small, focused LLM call to classify the situation. Is this alert actionable? Does this data pattern represent a real issue or normal variation? Is this new content something that needs review? The triage call uses minimal context and a short prompt to make a binary or categorical decision quickly and cheaply.

Full analysis. Only when the triage call identifies a situation requiring action does the agent load full context and make detailed LLM calls for analysis, decision-making, and action planning. This full analysis might involve multiple tool calls, extended reasoning, and detailed output generation. Because it only runs when genuinely needed, the cost is justified.

This tiered approach means that a typical tick costs almost nothing (just the pre-check). An interesting tick costs a small amount (pre-check plus triage). Only ticks that require real action incur the full cost of agent reasoning. Over thousands of ticks, the savings compared to running full analysis on every tick are substantial.

State Between Ticks

Tick-based agents face a design choice about how much state to maintain between ticks. The two extremes are fully stateless and fully stateful, with most production agents falling somewhere between.

Stateless ticks treat each tick as an independent evaluation. The agent observes the current environment, makes decisions based purely on what it sees now, and takes action without reference to previous ticks. Stateless ticks are simple and self-healing (no accumulated state that can become corrupted) but cannot detect trends, suppress duplicate alerts, or make decisions based on changes over time. If the same alert condition persists across 100 ticks, a stateless agent generates 100 alerts.

Stateful ticks maintain context across ticks. The agent remembers what it observed on previous ticks, what actions it took, and what results those actions produced. This enables trend detection (the error rate has been rising for the last six ticks), alert deduplication (this condition was already alerted on the last tick, do not alert again), progressive escalation (first tick sends a notification, third tick pages the on-call engineer), and adaptive behavior (this type of issue has been occurring frequently, adjust the monitoring threshold).

The state between ticks can be stored in memory (fastest, lost on restart), in a local file (durable, simple), in a database (durable, shared across instances), or in a dedicated state store like Redis (fast, durable, shareable). The choice depends on how much state there is, whether multiple agent instances need to share it, and how important it is to survive restarts.

A practical middle ground is to maintain a small, well-defined state structure between ticks. This structure typically includes the timestamp and result of the last tick, a counter of consecutive anomalous ticks (for progressive escalation), a set of currently active alerts (for deduplication), and any thresholds or parameters that the agent has adapted based on observations. This limited state provides the most valuable cross-tick capabilities without accumulating excessive state that can drift or become corrupted.

Common Tick-Based Applications

System health monitoring. An agent that checks system metrics every minute: CPU utilization, memory usage, disk space, network latency, error rates, queue depths. When metrics exceed thresholds, the agent investigates using logs and traces, diagnoses the likely cause, and either takes corrective action (restarting a service, clearing a cache, scaling up resources) or alerts the appropriate team with a diagnosis and recommended action.

Content moderation. An agent that reviews new user-generated content every five minutes. It pulls unreviewed items from the moderation queue, evaluates each one against community guidelines, approves acceptable content, flags borderline content for human review, and removes clearly violating content. The tick interval determines the maximum time before problematic content is detected.

Data quality assurance. An agent that validates data pipeline outputs every fifteen minutes. It compares current data against historical patterns, checks for completeness (are all expected data sources represented), consistency (do related metrics agree), and freshness (is the data current or stale). When it detects anomalies, it traces the issue to the source pipeline stage and creates a ticket for the data engineering team.

Resource cleanup. An agent that scans for stale resources every hour: expired temporary files, orphaned database records, unused cloud resources, stale cache entries, abandoned sessions. It evaluates each resource against retention policies, logs what it finds, and either cleans up automatically (for low-risk resources) or reports a list for human approval (for high-value resources).

Competitive monitoring. An agent that checks competitor websites daily for changes in pricing, features, messaging, or job postings. It compares current observations against the previous day's snapshot, identifies meaningful changes, and produces a summary for the product or marketing team. Daily frequency is appropriate because competitive information rarely changes faster than that.

Tick Overlaps and Guards

A potential issue with tick-based execution is tick overlap: the previous tick has not finished when the next tick fires. If the action phase of a tick takes longer than the tick interval, multiple ticks can be running simultaneously, which can cause duplicate actions, resource contention, and inconsistent state.

The standard solution is a lock or guard that prevents concurrent tick execution. Before starting a tick, the agent checks whether a previous tick is still running. If it is, the current tick is skipped. The lock can be implemented as a simple boolean flag in memory, a lock file on disk, or a distributed lock in Redis or a database for multi-instance deployments.

When ticks are regularly skipped due to overlaps, it is a signal that the tick interval is too short for the workload. Either increase the interval, optimize the tick processing to be faster, or split the workload across multiple agents with different schedules so each individual agent can complete its tick within the interval.