2026-11-07 - Why Messages Between Long-Running AI Agents End: A Month of Chains with No Cap, and What Would Tip Them

Abstract

When long-running AI agents may message each other directly, with no cap on the conversation, what stops replies from setting off replies? Builders answer with a cap because the published failures are runaway loops, so a system that stays finite without one shows what the cap stands in for, and what would make one necessary. We measured it on our own system: seventeen persistent Claude seats that run one business and message each other through committed mailbox files, over four weeks and 2,586 sessions. Nothing inside the conversation ends a chain: no hop cap, no rate limit on seat-to-seat sends.

Each turn a seat took because another seat's message woke it sent on 0.629 messages on average, and no week reached one, while seat-to-seat turns grew from 35% to 44% of all turns. We predicted, before counting, that messages which close something would end their chains; by the bar we set, they did not: a turn woken by an asking message sent on 0.862, one woken by a closing message 0.504, and 63.3% of close-woken turns sent nothing, short of the 70% we predicted. Messages are not lost: 36 of 4,908 sends (0.7%) show no sign of delivery.

So the chains end without a cap, and not because any one kind of message is final. Why the average stays under one is theory here, with a test for each part. Even if every answer, close and FYI were followed by one send, the average would reach about 0.89, so no single habit of acknowledging tips it; a rule that applies to its own output can. At each review of the messaging rules we will report the sends after answers and closes beside the average, and a designed rule that seats reply only when asked stays parked until that number moves.

1. Introduction

When long-running AI agents may message each other directly, what stops the replies from setting off replies? The usual answer is a cap: a turn limit, a hop limit, a budget, a token that declares the exchange done. The published failures are exchanges that had only a cap to stop them. Two role-playing copies of one model fell into "an infinite loop of meaningless conversation" (CAMEL, § 4); two agents in Anthropic's shop experiment chatted all night (Project Vend phase two); two models made to debate for a fixed 20 turns settle into model-specific endpoint regions (Ko & Geiping 2026, Sec. 4.3). A static analysis of 6,549 open-source agent projects found 68 loops with no effective bound, 14 of them multi-agent chat with no turn limit, and advises developers not to "rely on the model to eventually stop" (arXiv:2607.01641, § V-B1, § VI-A).

We run a business on seventeen long-running AI seats that message each other with no cap on the conversation itself, and a loop that keeps them working while the one human is away. Our seat conversation is the kind that analysis calls multi-agent chat without a turn bound. It ends. On 2026-11-07 the owner asked why: "Are there reasons other than 'they just do'? … What would need to be slightly off for this to fail?" This report answers three questions from our own record:

1. Do the chains still end, a month on, as the seats' traffic grew against the human's?
2. What does the kind of message that arrives do to what follows it?
3. Do chains end because messages are lost?

and then, as theory with a test for each part and none of the tests run, why it holds, what would tip it, and what would prevent that (§ 4).

2. Setting and data

The seats. Seventeen strategist seats, each holding one domain of a calligraphy business (the website, security, the product data, research, and others), each a chain of Claude Code sessions that carry a short handoff note across restarts. The seats ran Claude Opus 5.5, with a few sessions on Claude Fable 5.1. One human decides; he types to seats in their terminals. Until 2026-10-04 the seats could not message each other: for months the human carried their messages between them by hand, and seats were given direct messaging after those relayed exchanges had been seen to end (in his account, runaways happened twice in thousands of relayed messages).

How a message moves. A seat writes a message as a file in the recipient's mailbox, commits it, and sends a short ping naming the file and its commit; the recipient's session receives the ping as a turn, or, if it is mid-turn, as a note queued into the turn already running. Each file's name carries a type the sender chooses: FYI, ANSWER, CLOSE-LOOP, ACTION, FINDING, ASK and others (10,951 files added in the window; FYI 2,549, ANSWER 1,714, CLOSE-LOOP 1,656, ACTION 741, FINDING 663, ASK 544). The mailbox convention marks FYI "No reply needed" and lets a sender flag a message as needing an answer; seven seats' start-up checks read that flag, and nothing reads it at delivery.

What can stop a chain, read from the code on 2026-11-07. Each seat's sessions run inside a loop that relaunches the session when it ends and decides what the seat is told between turns; it has a standby mode, in which the seat waits for mail, and a keep-going mode, in which it works on its own goal. Nothing inside the conversation stops a chain. There is no hop cap on a thread and no rate limit on seat-to-seat sends. A seat that waits in the loop's standby mode is told "When mail or a ping arrives, handle it now … and reply to the sender." A seat in the loop's keep-going mode is told to do the most valuable next act or rest, and nothing about replying. Keep-going is the mode most sessions ran: 2,601 transcripts in the window carry its header, and at most 311 carry the standby text (an upper bound, since it counts sessions that quote it). The month therefore does not test the reply instruction. The outer stops are the loop's own: an iteration cap, a valve that lets a seat rest after three turn-ends with no commit, and a switch that turns seat-to-seat delivery off. A per-seat daily spend budget was built in October and is active for no seat.

Data. Every strategist session transcript in the project's three account stores, 2026-10-10T00:00Z to 2026-11-07T00:00Z: 2,586 sessions, 17,610 turns. Two earlier windows under the same rule: 2026-10-04 → 10-07 (288 sessions) and 10-07 → 10-10 (112 sessions).

Definitions. A turn is classified by what opened it, under a rule frozen before the first window was read: typed by the human, a loop's launch or keep-going prompt, a task notification, or a peer's ping (a peer turn). R is the mean number of seat-to-seat messages a peer turn sends. A chain is a root turn and the peer turns its sends open, hop by hop. A peer turn's kind is the type in the mailbox filename its waking ping names; a ping naming no mailbox file is NONE. Kinds were grouped before they were counted: asks (ASK, REQUEST, QUESTION, ACTION, PUSH, REVIEW, WAKE), closes (CLOSE-LOOP, CLOSE, LIVE, DONE, ACK, and FYI, which the convention marks as needing no reply), and other (everything else, including ANSWER, FINDING, RULING, and Q, the commonest question label, which the frozen list missed).

3. Results

3.1 Chains still end, as the seats' traffic grew against the human's

Each peer turn sent on 0.629 messages over the four weeks, and no week reached one. The three windows read 0.511, 0.60 and 0.629, rising each time; within the month the weeks read 0.69, 0.59, 0.66, 0.58 and 0.64, with partial weeks at both ends and no trend toward one. So R has risen since early October and has held flat for the four weeks. Meanwhile the seats' traffic with each other grew against the human's: peer turns rose from 35% of all turns (746 of 2,146) to 44% (7,801 of 17,610), and from 1.35 to 2.79 per turn he typed; per day, peer turns rose from 186.5 to 278.6 while his typed turns fell from 138 to 100. Peer turns more than 30 minutes after his last typed turn rose from 12% to 21% of peer turns; the longest such run was 99 turns across eight seats over seven hours.

The deep chains are work. We read by hand the cases most likely to be a storm: the deepest chain and all seven deep chains with no work turn. The deepest (ten hops between the lesson seat and the website seat, six minutes) settled a redirect's scope, corrected a lesson tile, named a schema field's owner and launched four builder jobs. The seven are release notices going to the seat that pushes to production, the push, and a CLOSE-LOOP saying it is live; a cold-check finding answered; two photographs cut and named; a security alert triaged as an instrument fault. Every message names a committed file. None is an acknowledgment loop or talk about the exchange itself; each settles something outside the conversation. The work in them is a production push or an image cut, which the work definition does not count.

Talks the owner opened end on agreement too. The hand read covers the chains likeliest to be storms, so it leaves out the exchanges nearest open dialogue: the owner telling seats to talk something out and come back with what they decide. Of the requests of that kind that a search of his typed turns found from 2026-10-04 on, we coded the eight whose topic could be followed in the mail log, all inside the month; two readers coded each, the research seat and a fresh model that had not seen its coding. All eight ended in an agreement or a decision. Seven reached it within about seven minutes of their first message, after two to four messages; the eighth, which brought in a third seat, took thirty minutes. Three were about the seats themselves (which seat owns a tool, which seat acts on each monitoring signal, which seat chooses a post's tags and which places them); five settled work (a release's scope, a reading rule, a page section, a plan, an article). In four, the seats sent the owner a joint recommendation and his ruling closed it; in one, a seat decided after hearing from two others. Agreement was not always final: one plan was retired the next day, when the measurement it waited on came back against it, and one item of a release's scope was withdrawn two minutes after it was agreed, when a third seat narrowed it.

The average hides pairs above one. Of 71 sender-receiver pairs with 20 or more peer turns, 7 send on one or more per turn. They end at three seats: three at the seat founded on 2026-10-07 to serve the others' writing questions, three at the website-content seat, and one at the production seat. No pair's reverse is among the seven, so none is two seats answering each other; and the chains they sit in still end, at ten hops at most.

3.2 A message's kind shifts what follows, and closing messages were not terminal by our bar

A turn woken by an asking message sent on 0.862 messages; one woken by a closing message, 0.504. We had predicted, in writing before the count, that closes would be terminal: R after a close below half of R after an ask, and 70% of close-woken turns sending nothing. Both failed. Half of R after an ask is 0.431, and 63.3% of close-woken turns sent nothing. Moving Q into the asks group would raise its R to about 0.90; the failure stands.

The order held in every week of the month: closes between 0.48 and 0.64, asks between 0.74 and 1.05, above one in one week. Over a third of close-woken turns (36.7%) still sent something. Closes are somewhat more likely to end a chain than their share predicts: they woke the last turn of 1,476 of 3,201 chains (46.1%), against 41.6% of peer turns, and asks woke 407 (12.7%), against 18.7%. Two small kinds are terminal on the bar by themselves: DONE (45 turns, R 0.267, 75.6% sending nothing) and HOLD (30 turns, 73.3%).

Few kinds send on one or more. (A reading of the table after the prediction failed, not a frozen test; the five are picked by their R.) Five kinds of 30 turns or more send on one or more: questions (Q 1.13, QUESTION 1.08), findings (1.04), reviews (1.06) and routings (1.01). Together they are 825 of the 7,801 peer turns (10.6%), sending on 1.064. The commonest kinds send on about half: FYI 0.548, ANSWER 0.500, CLOSE-LOOP 0.457.

3.3 Messages are not lost

Of 4,908 sends from peer turns, 36 (0.7%) show no sign of delivery. 3,046 opened a peer turn at the recipient within 30 minutes and 41 more within the count's tolerance; 1,761 were delivered into a turn the recipient already had running, where the transcript records the ping as a queued note whose text matches the send. Of the remaining 60, 11 name a recipient the count could not resolve, and of the other 49, 13 had a note from the sender arrive whose text did not match, which leaves the 36. So the rival explanation, that chains end because messages never arrive, does not hold.

A ping often joins work in progress. 3,421 pings (30.5% of the 11,222 delivered) joined a running turn instead of opening one. Sends from peer turns join a running turn more often than other sends: 1,761 of 4,908 (35.9%), against 21.8–24.1% of sends from turns the human typed, the loop launched or a task notification opened (297 of 1,363; 545 of 2,265; 668 of 2,972).

4. Why it holds, what would tip it, what would prevent it

Theory. Each part is tied to a number above or marked as our reading, and each has a test; none of the tests has been run.

Where the edge is. Split the traffic in two: the five branching kinds (825 turns, R 1.064) and everything else (6,976 turns, R 0.578). Holding the rest at 0.578, the branching kinds would have to grow from 10.6% of peer turns to 86.8% for the mean to reach one. Holding the mix, the rest would have to rise from 0.578 to 0.99. On this split the margin is in the rest of the traffic, not in the branching kinds multiplying. The rest is not only replies: it holds asks such as PUSH (0.946) and REQUEST (0.964) beside the answers and closes, and the split is drawn by R after the fact. (The mean is a first-order criterion. For a process with several message kinds the exact one is the largest eigenvalue of the kind-to-kind matrix, which needs the kind of each send as well as of each waking message; this count has only the second. Five kinds already send on one or more, so if they mostly set each other off, a subset could sustain itself while the mean stays under one; the matrix would show it, and the chains ending at ten hops at most says it has not happened this month.)

Why it holds now. - Few kinds send on one or more, and the commonest send on about half (§ 3.2). - Messages arrive into work. Three in ten pings join a running turn (§ 3.3). Our reading: a busy seat handles several messages in one turn, so they share one set of onward sends. Test: onward sends per turn against the number of pings it absorbed. - Each chain is about something outside the conversation that can be settled. The eight chains read by hand concern a piece of work (a page, an image, a rule, an alert) and end when that work does, and the eight talks the owner opened end on an agreement or a decision, three of them about how the seats divide their own work (§ 3.1). So what is settled can be a file, a decision, or the seats' division of labor. (That 93.3% of peer turns are opened by a ping naming a mailbox file says only that the message is itself a file; it is not evidence for this.) Our reading: an exchange ends when what it is about is settled; talk about the exchange itself (thanks, acknowledgment, the conversation as its own topic) has nothing to settle, which is the open-dialogue setting where the attractor literature finds drift. An owner who leaves the method open still names the question and asks for the answer back. Test: read a random sample of chains ending on a ruling or an answer, and ask what each settled. - The loop most sessions run does not tell them to reply (§ 2). Our reading, since the month has almost no standby sessions to compare. Test: R by the recipient's loop mode.

What would tip it. 1. Answering the answers. Any rule or habit that makes a seat acknowledge an ANSWER, a CLOSE-LOOP or an FYI raises the commonest part of the traffic (4,073 of 7,801 peer turns, sending on about one half). Alone it does not tip the average: with all three at one send apiece, the average would be about 0.89. It narrows the margin for every other change on this list. Its forms: the standby instruction to reply carried into the keep-going mode, an acknowledge-on-receipt convention, a gate that wants a reply to every mail. Test: R after answers and closes, weekly; acknowledgment files per week (27 in the window). 2. A rule that applies to its own output, the one change here that multiplies rather than adds, such as a notice required on every committed message where the notice is itself a committed message (the recursive sub-agent spawn reported in claude-code issue #69578 has this shape). Test: at any new rule about messages, R of the kind of message that rule produces. 3. Idle seats. With more seats and less work each, every ping opens its own turn instead of joining one. Test: R by whether the recipient was mid-turn. 4. Two owners of one decision. A question with two answerers, or two seats each correcting the other, is a loop with content. None of the seven pairs above one is mutual this month (§ 3.1). Test: a pair above one whose reverse is also above one. 5. A model with a stronger pull to reply or reflect. Ko & Geiping measure Claude Haiku 4.5 pulling its partners toward commentary on the conversation itself and toward termination language. Test: R by kind at each change of the seats' model.

What would prevent it. - Measure the edge, not only the average: report R after answers and closes beside R at each review, and read every alarm's chains by hand before acting (a mechanical alarm for deep chains with no work fired seven times this month, all on push sequences). - Keep the instruction to reply from spreading, and say which messages need none. A rule that a seat replies only when the message asks is designed and parked; the convention already marks FYI as needing no reply. - Keep the outer stops: the delivery switch, the loop's iteration cap and its rest valve. The spend budget exists and is off.

Related work

The counts nearest ours are reply counts among LLM agents on Moltbook, a public social network for agents, and both systems lose depth fast. In Moltbook's first week, 9.60% of 223,316 comments drew any direct reply; a post drew 5.57 direct replies on average, a top-level comment 0.153 and a reply to it 0.008, and all comments below the post together 0.134 (Eziz 2026, § 6.1.1, § 6.2.2, § 6.2.5). Over its first three and a half days, 6.5% of 115,031 comments drew a reply, 0.07 replies per comment, and no thread went deeper than five (Holtz 2026, § 4.3, Table 4). Both counts are descriptive. A reply there is a comment whose parent link points at another; Eziz says his depth figure is "not a directly identified branching ratio" (§ 6.2.1), and neither paper establishes why threads end. Eziz tests the often-repeated claim that Moltbook agents wake on a four-hour schedule and finds only "extremely weak concentration" (§ 6.5); Holtz finds 34.1% of messages are exact duplicates (§ 4.4). Our R is not the same quantity: it counts every message a seat sends from a turn that another seat's message opened, to anyone, so it includes handing the next step to a third seat, which a reply link does not. It sits above both papers' figures for comments and far below their figures for posts (Holtz's posts drew 7.70 direct replies, Table 4). What separates the settings, as far as either paper reports: a Moltbook comment goes into a public thread that anyone may answer and nobody must, and most of the traffic is social (Eziz's Social/Casual category holds 189,765 of the 223,316 comments, Table 2); a message of ours goes to one seat, names a committed file, and is about work that ends.

Inside task-doing LLM teams, the traffic has been counted but not what it sets off. Destefanis and Aste (2026) logged every message in 1,902 runs of Claude Code coding teams on one model, claude-sonnet-4-6 (§ 3): messages per run rise from 6.1 at two agents to 71.3 at eight (Table 1), while messages per ordered pair fall from about three to 1.27 (§ 4). Their instrument records sender, recipient, size and time, and "does not capture message content" (§ 2, § 4), so it cannot say which message answered which; each run is a fresh team that ends when the task does (§ 2). Electric Elves, nine persistent per-person agents in a research office from June 2000, published daily message counts over seven months and no chains (Chalupsky et al. 2001).

The exchanges in § 1 had nothing to end on but the cap. CAMEL's role-play and Ko and Geiping's debates are open dialogue with an assigned role and no outcome, the debates run a fixed 20 turns with no rule for stopping early (Ko and Geiping 2026, Sec. 3); the 68 unbounded loops of arXiv:2607.01641 are found by reading code, and that paper is a static analyzer that runs no agents (§ IV). The chains we read differ from all of them on that one property: each is about something outside the conversation, a piece of work or a decision, and ends when that is settled (§ 3.1, § 4). That holds where the method is left open too: when the owner tells seats to talk something out, he names the question and asks for what they decide, which the role-play and the debates do not have.

We found no published count of how often a message between persistent, task-doing LLM agents sets off further messages. The search, to 2026-11-07: the literature pass for the brakes study of October, three scans for our earlier paper on this messaging, two web queries, and a scan aimed at this sentence. Every lead it returned that could break the sentence is read above at the primary: the two Moltbook papers count replies in a social feed, and the coding-team study counts messages but not what they set off. Two further leads count other things: the dependency graph of model calls in a two-week production serving trace (read to its abstract), and sub-agent spawn fan-out in coding sessions (not opened; described from the scan's summary only).

Bounds

• One business, one model family, one month.
• Chains across restarts. A chain carried on through a loop's restart is counted as a new chain, so long chains may be split; and the loop's own launch turns sent on 0.93 and 1.09 per turn in two weeks of the month, so a low R for peer turns does not mean the loop's turns are low.
• Work is mechanical. It counts commits, edits outside the mailbox and builder jobs, and misses a production push or a decision written in prose; the deep chains with no work turn are push sequences for that reason.
• The kind is the sender's label. A FYI that asks a question counts as a close; 9.8% of peer turns carry no label at all.
• § 3.2's last paragraph and § 4's split are post hoc. The frozen prediction failed; the five kinds were picked from the table afterward, by their R.
• Loop mode is counted roughly. The 2,601 and 311 are file counts over all transcripts in the window, not the 2,586 sessions of the main count.
• The window is closed at both ends. Eight sends in the last 30 minutes could not be followed.
• The delivery count was refined after its first run. Its first pass had no category for delivery into a running turn; that was added after the first unlinked count was seen, and no linked or unlinked count changed.
• The hand read is 8 of 499 deep chains, chosen as the likeliest storms, not drawn; the talks the owner opened are those a search of his typed turns found, not all of them.
• Ending is not being right. This paper measures whether exchanges end, not whether what they settle is correct; in the same month the owner corrected exchanges that had settled a question outside the seats' own domains (one seat directing a change in another's tool, two seats answering a third's question instead of sending it to its owner).
• Owner's account. The history of hand relay before 2026-10-04 and its two runaways are the owner's account, not counted here.
• § 4 is theory. Its arithmetic is first-order, and none of its tests has been run.

Conclusion

A turn our seats take because another seat messaged them sends on fewer than one message, and the average held for a month while the seats' traffic with each other grew against the human's, with no cap inside the conversation. Talks the owner opened between seats ended on an agreement or a decision as well, most within minutes. Messages are not lost. Closing messages are followed by fewer sends than asking ones, and slightly more often end a chain, but they are not final: over a third of them are followed by a send. Why the average stays under one is theory here: few kinds of message send on more than one, and the commonest send on about half, so a habit of answering the answers would narrow the margin, though by itself it would leave the average under one; what would tip it is a rule that applies to its own output. The sends after answers and closes are the number to watch beside the average.

Falsifiers

• Chains end (§ 3.1). Any week with R at or above one, or R rising three weeks running. Read at the re-run on 2026-11-21 and at each review of the messaging rules.
• Closing messages are not terminal (§ 3.2). In the next window, R after a close below half of R after an ask and 70% or more of close-woken turns sending nothing: then closes are terminal after all and § 3.2's first finding is wrong. Read 2026-11-21.
• Messages are not lost (§ 3.3). More than 5% of sends from peer turns showing no sign of delivery in the next window. Read 2026-11-21.
• The margin is in the rest of the traffic, and only a self-applying rule tips it (§ 4, theory). R rising toward one while R after answers and closes stays near one half, which would put the margin in the branching kinds' share instead; or R at one with no new rule about messages, which would mean something other than a self-applying rule can tip it. Read at any week with R at or above 0.8, and at any new rule about messages or change of the seats' model.
• The deep chains are work (§ 3.1). A deep chain, read by hand at any alarm, that is an acknowledgment loop or talk about the exchange itself, with nothing outside the conversation to settle.

Authors and AI use

Tim Jackowski, who runs the business and its AI seats, asked the question on 2026-11-07 and set the paper's terms: report what was measured, and theorize what would break it. str-kotowari, the research seat (Claude Opus 5.5), designed the measurements, froze the by-kind prediction before the count, read the deep chains and the literature, and drafted the paper. Its implementer (Claude Sonnet 5.5) built the by-kind count and the delivery check; the research seat reviewed its output. A read-only investigator (Claude Sonnet) read the messaging code for § 2, another coded the talks the owner opened from the mail log without seeing the research seat's coding, and read-only workers (Claude Sonnet) read the cited papers whole, each figure quoted here checked against the saved text. xAI's Grok, through its command-line tool, ran the literature scan aimed at the absence sentence in Related work (model version not recorded); its leads were read at the primary before any was cited. Grok (grok-4.7, through its agentic command-line tool, with the repository) read the whole draft against the data and the cited papers; its objections narrowed the claims in § 3.2 and § 4 and the abstract. A blind panel of Grok (grok-4.6) and Google's Gemini (gemini-3.1-pro-preview) scored § 4's theory; OpenAI's member did not run. Claude Sonnet 5.5 read the public version cold, with no other context. None of them wrote any of the paper. Tim read the finished paper, gave two notes that changed § 3.1 and § 4, and approved publication. Our security role, also Claude Opus 5.5, cleared what the paper discloses.

Authors · str-kotowari, Research Strategist (Anthropic Claude Opus 5.5, Takase Studios LLC) · Tim Jackowski (Systems Architect, Takase Studios, LLC)

AI written · Read and published by Tim Jackowski.