What do “24/7 agents” do? Three configurations and one public run

A Hacker News poster, CuriousRose, asks what people’s “24/7 agents” actually do, how capable the models are, and what they cost. The poster describes a SaaS backlog and difficulty understanding how useful outputs emerge and where a person belongs in the process. This is a reader’s question, not evidence that the reported deployments work or that any particular architecture dominates.

The supplied originals offer a bounded example to investigate. A Team Status configuration in github/gh-aw and a Repo Status configuration in githubnext/agentics ask for repository activity reports. A separate Cost Tracker configuration in githubnext/agentics describes reporting costs after named workflows finish. These are specific configured jobs, not a representative sample of all agent deployments.

The pinned daily-team-status.md frontmatter specifies a daily schedule and manual invocation. It declares read permissions for repository contents, issues and pull requests. Separately, its safe-outputs block authorizes constrained issue creation and handling of older reports. Read permissions in one layer therefore do not mean that the complete system has no writing path: the report itself is an intended write through a controlled output mechanism.

The Team Status bash allowlist names cat, ls, find, grep, head, tail and wc. Its output configuration specifies a title prefix, fixed labels, disabled mentions, an empty allowed-reference list and closure of older issues. These are explicit boundaries in the supplied configuration. They are useful to inspect, but the file alone does not prove enforcement against every misuse, a maximum number of internal model calls, or that the resulting report is correct.

Repo Status is a separate file from a different repository; the materials do not establish that it is an earlier version of Team Status. Their reporting instructions and some permission and tool declarations are similar, while their title prefixes and process descriptions differ. Cost Tracker instead declares a completed-workflow trigger, read-all permissions and broader tools, including bash: true. A common agent-workflow label does not make these three capability sets interchangeable.

The captured public summary for Team Status run #336 reports a scheduled trigger on October 18, 2026 at 11:30 and Status: Success, with total duration 4m 45s. The displayed stages are activation 41s, agent 2m 19s, detection 47s, safe_outputs 15s and conclusion 24s. These are the page’s displayed timings, not a measured token bill or proof that a model worked continuously throughout the run. They should not be added up and presented as billed runner usage.

The page lists eight artifacts. The agent artifact is shown as 446 KB, agent-output-fallback as 4.33 KB and usage as 73.4 KB. Those are artifact names and displayed sizes; they do not identify the amount of model-generated text, prove that a fallback was activated, or reveal the number of model and tool turns. The public summary requests sign-in for logs. The contents of these artifacts were not inspected in this study.

The captured summary does not show the generated report’s contents or a linked report that was independently assessed here. That does not prove the report itself is private or behind a login wall. The success label is evidence of the recorded workflow conclusion; it cannot establish the report’s factual quality, practical benefit, absence of human intervention or reliability over repeated daily runs.

Anthropic’s supplied engineering article distinguishes predefined orchestration from systems in which the model directs its own process and tool usage. This distinction is useful as an analytical lens, but a product name, a schedule or a short numbered prompt is not enough to apply it conclusively. The relevant question is which decisions code fixes and which decisions the model actually makes.

The configuration files establish triggers, declared capabilities, reporting instructions and permitted outputs. The public run establishes a visible outer sequence of jobs. Neither gives a complete trace of the agent stage. A fixed outer pipeline can contain a model-directed loop inside it; conversely, an agent-branded tool may perform a tightly prescribed task. Without the inner trace, claiming that the model never chooses a tool or that every step runs regardless of its output would exceed these originals.

For the reader, the useful boundary is operational: inspect what starts a run, what context and tools it can access, which outputs can reach the repository and where a person must verify usefulness. The observed schedule is different from continuous model activity. The example makes a recurring maintenance task concrete while leaving internal autonomy, general deployment prevalence and achieved value open.

The Cost Tracker source describes reading token-usage.jsonl, grouping usage by model, applying an embedded pricing table and posting a cost report or alert. Its example fields distinguish input, output, cache-read and cache-creation token counts. The declared calculation multiplies those counts by the corresponding per-million-token rates. This documents that implementation’s accounting design; its embedded rates are not verified current vendor prices, and its counting conventions are not automatically transferable to another provider’s bill.

The supplied tracker names agent-implement and agent-pr-fix as monitored workflows. That configuration does not establish that it was installed for Team Status, nor that no other cost report exists. Its $1.00 high-spend threshold is a configured alert setting. It is neither an observed typical cost, a spending cap nor evidence that the run cost less than a dollar.

No actual dollar cost for run #336 was established from the supplied public materials. A complete comparison would need the relevant model-usage records and their pricing basis, applicable runner charges and any retry or review work. The displayed total duration alone cannot produce that bill. Cost Tracker shows a way to collect evidence; the presence of a usage artifact and a conversion formula does not provide the missing measured amount.

The concrete work in these examples is repository reporting and cost reporting, with different triggers and capability boundaries. The public Team Status run supplies an observable execution result and timing, while the configuration supplies intended behavior. Reading both is more useful than treating “24/7” as a specification: distinguish the schedule, the actions permitted during a run, and the output that a person can inspect.

Before adopting a similar job, require an inspectable output tied to its configuration and run, judge its accuracy and usefulness, and collect complete usage and cost records over comparable runs. These are proposed acceptance steps, not outcomes already measured here. This study cannot rank frontier-model capability, establish a typical success rate or ROI, or answer how much repair a team would need after autonomous overnight work. One successful summary is a starting point for that evaluation.