coilyco-gaming/sirens-echo

Watch

Echo has no clock, so no question about the current time can be answered #855

New issue

Closed

opened 2026-08-16 02:55:21 +00:00 by coilyco-ops · 2 comments

coilyco-ops commented

2026-08-16 02:55:21 +00:00

Member

Split out of #851, which turned out to be a different problem. This is the part of #848 that the discord-timestamps resource does not reach.

The gap

Echo has no access to the current time. There is no current-time injection anywhere in her system prompt material (agent/*.yaml, agent/rendered/*.prompt.txt), and no time-reporting tool in her roster. Every time.Now() in internal/community/ is runtime bookkeeping such as timeouts, job stamps, and rate limiting, none of which reaches the model.

So a question like "what time is it in Paris" has no answer available to her, and neither does any question of the form "how long ago was X" against a wall clock.

Why the timestamps resource does not close it

deploy/services/sirens-echo/discord-mcp.mcp.kdl serves ward://discord/timestamps, which explains how to render <t:EPOCH:STYLE> so each Discord reader sees their own timezone. That resource is correct and worth having, and #851 plus deploy PR 570 make Echo actually read it.

It still does not help here, and says so itself:

THE PART THIS DOES NOT SOLVE. Emitting the markup needs an epoch, and turning a phrase like Saturday 8pm into one needs the SPEAKER'S timezone.

Rendering a known epoch and knowing the current epoch are separate capabilities. Echo has neither today, and the resource only ever addressed the first.

Shape of a fix

The narrow version is the current UTC epoch, stated once per turn in the system message the way other turn-local facts already are. That answers "what time is it" and gives an epoch to render from, with no new egress and no MCP round trip.

Timezone conversion for a named city is a second, larger question. It needs a tz database rather than a clock, and it is worth deciding separately whether that belongs in Echo at all.

Worth noting the resource's own warning survives either way: Discord does not expose member timezones, so turning a phrase like "Saturday 8pm" into an epoch still needs the speaker to say which timezone they mean.

Provenance

#848 was filed by the live Sirens Echo MCP and carries the sandboxed label. This issue restates the underlying gap from the repository rather than from that report, and the code and spec references above were read directly.

Split out of #851, which turned out to be a different problem. This is the part of #848 that the `discord-timestamps` resource does not reach. ## The gap Echo has no access to the current time. There is no current-time injection anywhere in her system prompt material (`agent/*.yaml`, `agent/rendered/*.prompt.txt`), and no time-reporting tool in her roster. Every `time.Now()` in `internal/community/` is runtime bookkeeping such as timeouts, job stamps, and rate limiting, none of which reaches the model. So a question like "what time is it in Paris" has no answer available to her, and neither does any question of the form "how long ago was X" against a wall clock. ## Why the timestamps resource does not close it `deploy/services/sirens-echo/discord-mcp.mcp.kdl` serves `ward://discord/timestamps`, which explains how to render `<t:EPOCH:STYLE>` so each Discord reader sees their own timezone. That resource is correct and worth having, and #851 plus deploy PR 570 make Echo actually read it. It still does not help here, and says so itself: > THE PART THIS DOES NOT SOLVE. Emitting the markup needs an epoch, and turning a phrase like Saturday 8pm into one needs the SPEAKER'S timezone. Rendering a known epoch and knowing the current epoch are separate capabilities. Echo has neither today, and the resource only ever addressed the first. ## Shape of a fix The narrow version is the current UTC epoch, stated once per turn in the system message the way other turn-local facts already are. That answers "what time is it" and gives an epoch to render from, with no new egress and no MCP round trip. Timezone conversion for a named city is a second, larger question. It needs a tz database rather than a clock, and it is worth deciding separately whether that belongs in Echo at all. Worth noting the resource's own warning survives either way: Discord does not expose member timezones, so turning a phrase like "Saturday 8pm" into an epoch still needs the speaker to say which timezone they mean. ## Provenance #848 was filed by the live Sirens Echo MCP and carries the sandboxed label. This issue restates the underlying gap from the repository rather than from that report, and the code and spec references above were read directly.

coilyco-ops referenced this issue

2026-08-16 02:55:36 +00:00

The harness doesn't know how to read MCP "resources" #851

coilyco-ops added the

labels

2026-08-17 16:33:42 +00:00

coilyco-ops referenced this issue

2026-08-17 18:08:19 +00:00

The harness doesn't know how to read MCP "resources" #851

coilyco-ops commented

2026-08-17 18:09:19 +00:00

Author

Member

Decision: inject the time per turn, outside the cached system prompt

Decided by Kai, 2026-08-17, recorded by Darren (director seat).

The choice

The current time reaches Echo as per-turn context, on the same route attachments, the progress line and the reactions already take. It does not go into the system prompt.

Why the placement is the whole decision

The obvious fix is one line in the system prompt. That would be a mistake, and naming why is the point of this record.

#162 is about Echo shipping a 53 KB system prompt on every turn, byte-identical and uncached, and the fix for it is caching that prompt. A timestamp in the system prompt changes it every turn by construction, so it would permanently foreclose #162. The cheapest version of this fix quietly spends a larger, already-identified saving.

Per-turn injection outside the system prompt costs nothing in caching, needs no tool round trip, and answers the question class immediately.

What this forecloses

A time tool in the roster. Not chosen. It would also have been caching-safe and it would have made the lookup visible in telemetry, but it spends one of the 6 tool rounds and adds latency to a p99 turn already sitting at the 180s ceiling per #577.
System prompt injection. Explicitly rejected, for the reason above. If someone implements this by editing the prompt, they have reverted #162 without saying so.

What it unblocks

ward://discord/timestamps becomes functional. That resource teaches Echo to emit <t:EPOCH:STYLE> so every reader sees their own timezone, and it currently says of itself that emitting the markup needs an epoch. Injection supplies the epoch. #851 is now closed confirming the harness does read that resource, so the guidance is reaching her already and only the input was missing.

The resource's own caveat still stands and is not solved here: turning "Saturday 8pm" into an epoch needs the speaker's timezone, which Discord does not expose. Ask, or state the assumption. Do not infer a timezone from a name or a channel.

Revisit condition

If per-turn injection turns out to drift, because a long turn answers with the time it started rather than the time it replied, switch to the tool. A wrong clock is worse than no clock.

Staying priority/P2, autonomy/headless, role/engineer. Ready to dispatch.

## Decision: inject the time per turn, outside the cached system prompt **Decided by Kai, 2026-08-17, recorded by Darren (director seat).** ### The choice The current time reaches Echo as per-turn context, on the same route attachments, the progress line and the reactions already take. It does **not** go into the system prompt. ### Why the placement is the whole decision The obvious fix is one line in the system prompt. That would be a mistake, and naming why is the point of this record. #162 is about Echo shipping a 53 KB system prompt on every turn, byte-identical and uncached, and the fix for it is caching that prompt. **A timestamp in the system prompt changes it every turn by construction**, so it would permanently foreclose #162. The cheapest version of this fix quietly spends a larger, already-identified saving. Per-turn injection outside the system prompt costs nothing in caching, needs no tool round trip, and answers the question class immediately. ### What this forecloses * **A time tool in the roster.** Not chosen. It would also have been caching-safe and it would have made the lookup visible in telemetry, but it spends one of the 6 tool rounds and adds latency to a p99 turn already sitting at the 180s ceiling per #577. * **System prompt injection.** Explicitly rejected, for the reason above. If someone implements this by editing the prompt, they have reverted #162 without saying so. ### What it unblocks `ward://discord/timestamps` becomes functional. That resource teaches Echo to emit `<t:EPOCH:STYLE>` so every reader sees their own timezone, and it currently says of itself that emitting the markup needs an epoch. Injection supplies the epoch. #851 is now closed confirming the harness does read that resource, so the guidance is reaching her already and only the input was missing. The resource's own caveat still stands and is not solved here: turning "Saturday 8pm" into an epoch needs the **speaker's** timezone, which Discord does not expose. Ask, or state the assumption. Do not infer a timezone from a name or a channel. ### Revisit condition If per-turn injection turns out to drift, because a long turn answers with the time it started rather than the time it replied, switch to the tool. A wrong clock is worse than no clock. Staying `priority/P2`, `autonomy/headless`, `role/engineer`. Ready to dispatch.

coilyco-ops referenced this issue

2026-08-17 18:11:40 +00:00

The harness doesn't know how to read MCP "resources" #851

coilyco-ops referenced this issue from a commit

2026-08-17 18:20:57 +00:00

feat: give the turn a clock

coilyco-ops referenced this issue from a pull request that will close it,

2026-08-17 18:21:13 +00:00

feat: give the turn a clock #917

coilyco-ops commented

2026-08-17 18:21:33 +00:00

Author

Member

Built and in review at #917. Angie (ENG, claude seat).

The narrow version, as you framed it: one system message directly under the local policy, stating the moment and its Unix epoch. No new egress and no MCP round trip.

Read once per turn rather than once per round. A turn that runs six tool rounds would otherwise carry six different answers to the same question inside one reply, and a test asserts the single read across a turn that repairs.

The message states the fact and nothing else. Rendering <t:EPOCH:STYLE> is what discord-timestamps already explains, and I verified on #851 today that the resource reaches Echo now: grounding_documents on the sirens-echo pods went 0, 0, 0, then 1 at 2026-08-16 15:00Z, after deploy PR 570 merged at 03:58Z. So repeating the rendering instruction here would duplicate a live one. Your framing was exactly right - rendering a known epoch and knowing the current epoch are separate capabilities, and this supplies the second.

Untouched, deliberately. Timezone conversion for a named city. It needs a tz database rather than a clock, and whether it belongs in Echo at all is the separate decision you named. The resource's own warning survives too: Discord exposes no member timezones, so turning "Saturday 8pm" into an epoch still needs the speaker to say which zone they mean.

Built and in review at https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/pulls/917. Angie (ENG, `claude` seat). The narrow version, as you framed it: one system message directly under the local policy, stating the moment and its Unix epoch. No new egress and no MCP round trip. **Read once per turn rather than once per round.** A turn that runs six tool rounds would otherwise carry six different answers to the same question inside one reply, and a test asserts the single read across a turn that repairs. **The message states the fact and nothing else.** Rendering `<t:EPOCH:STYLE>` is what `discord-timestamps` already explains, and I verified on #851 today that the resource reaches Echo now: `grounding_documents` on the `sirens-echo` pods went 0, 0, 0, then **1** at 2026-08-16 15:00Z, after deploy PR 570 merged at 03:58Z. So repeating the rendering instruction here would duplicate a live one. Your framing was exactly right - rendering a known epoch and knowing the current epoch are separate capabilities, and this supplies the second. **Untouched, deliberately.** Timezone conversion for a named city. It needs a tz database rather than a clock, and whether it belongs in Echo at all is the separate decision you named. The resource's own warning survives too: Discord exposes no member timezones, so turning "Saturday 8pm" into an epoch still needs the speaker to say which zone they mean.