coilyco-gaming/sirens-echo

Watch

On container start - deep picks 1 personality and 3 personal prefs to emphasize highly #781

New issue

Open

opened 2026-08-14 08:38:59 +00:00 by coilysiren · 2 comments

coilysiren commented

2026-08-14 08:38:59 +00:00

Owner

Replaces this much more complicated issue

#237

Resolved spec (design pass, 2026-08-15)

Decision - uniform random draw at container start, unseeded. Every restart reshuffles and no two replicas match. Date-seeded, container-ID-seeded, and model-chosen selection were all considered and declined.

Build

At container start, before the first turn, draw 1 personality from Deep's available personality set and 3 personal-preference skills from the personal-preference-* catalog. Uniform, without replacement inside each draw.
Emphasize the drawn items in the composed session prompt. "Emphasize highly" means the drawn items get an explicit foregrounding instruction, not that the undrawn ones are removed.
Log the draw once at startup at info severity, naming the selected personality and the three preferences, so a surprising reply can be traced back to its boot flavor. See #158 - severity must be populated on that line.

Acceptance

Two consecutive container starts with identical config produce different draws with high probability. A test seeds the RNG to assert the selection shape, not the specific values.
The drawn set is visible in startup logs and stable for the container's lifetime. No re-draw mid-turn or mid-session.
Undrawn personalities and preferences remain reachable, just not foregrounded.

Open, engineer's call - whether the draw is exposed on a diagnostic surface (a slash command or health field). Not required for close.

Supersedes #237.

Replaces this much more complicated issue https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/237 --- ## Resolved spec (design pass, 2026-08-15) **Decision** - uniform random draw at container start, unseeded. Every restart reshuffles and no two replicas match. Date-seeded, container-ID-seeded, and model-chosen selection were all considered and declined. **Build** 1. At container start, before the first turn, draw 1 personality from Deep's available personality set and 3 personal-preference skills from the `personal-preference-*` catalog. Uniform, without replacement inside each draw. 2. Emphasize the drawn items in the composed session prompt. "Emphasize highly" means the drawn items get an explicit foregrounding instruction, not that the undrawn ones are removed. 3. Log the draw once at startup at info severity, naming the selected personality and the three preferences, so a surprising reply can be traced back to its boot flavor. See #158 - severity must be populated on that line. **Acceptance** * Two consecutive container starts with identical config produce different draws with high probability. A test seeds the RNG to assert the selection shape, not the specific values. * The drawn set is visible in startup logs and stable for the container's lifetime. No re-draw mid-turn or mid-session. * Undrawn personalities and preferences remain reachable, just not foregrounded. **Open, engineer's call** - whether the draw is exposed on a diagnostic surface (a slash command or health field). Not required for close. **Supersedes** #237.

coilysiren referenced this issue

2026-08-14 08:39:38 +00:00

Allow the harness to reconfigure personas via slash command #237

coilysiren changed title from ~~On container start - pick 1 personality and 2 personal prefs to emphasize highly~~ to On container start - pick 1 personality and 3 personal prefs to emphasize highly

2026-08-14 08:41:23 +00:00

coilysiren commented

2026-08-14 08:42:11 +00:00

Author

Owner

3 prefers: 1 animal (always) + 2 media from distinct media types

coilysiren changed title from ~~On container start - pick 1 personality and 3 personal prefs to emphasize highly~~ to On container start - deep picks 1 personality and 3 personal prefs to emphasize highly

2026-08-14 16:49:46 +00:00

coilyco-ops added the

priority

autonomy

async-consult

labels

2026-08-15 15:17:40 +00:00

coilyco-ops referenced this issue

2026-08-15 15:54:30 +00:00

Give the agent first class understanding of discord roles #230

coilyco-ops added the

role/ai

label

2026-08-15 21:12:17 +00:00

coilyco-ops commented

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

Member

Decision: make the pick in the harness at startup, not in the model

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

The problem this issue would otherwise hit

This issue asks Deep to pick 1 personality and 3 personal preferences to emphasize on container start. Implemented the obvious way, that is the model choosing, and the model has no randomness. There is no random tool anywhere in the surface, and a language model asked to pick at random does not pick uniformly or unpredictably. It has strong favourites, and it will have the same ones every rollout.

So the naive version produces a feature that looks varied in review and is close to constant in production, which is the worst outcome available: nobody notices it is broken.

The choice

The selection happens in harness code at container start, where crypto/rand and math/rand are ordinary Go and genuinely available. The chosen personality and preferences are then injected as facts the model is told, rather than a decision the model makes.

Why this is better than a random tool

It is reproducible. Log the seed and the rollout's persona is explainable after the fact, which matters the first time someone asks why Deep was odd on Tuesday.
It adds nothing to the tool array, which #859 shows is already expensive, since every skill and tool description is concatenated into the prompt at boot and the skillpack is 79% of Echo's prompt.
It happens once per rollout rather than once per turn, matching what this issue actually asks for.

What this forecloses

A general random tool on the model surface. Not chosen here. If a later feature needs a fair pick during a turn rather than at startup, that is a different issue and this decision does not settle it.

Note for the wider surface

The absence of randomness is not recorded anywhere else and it was found by audit rather than by failure. Anything else that wants a genuine unpredictable or uniform choice has the same problem and the same answer: do it in the harness.

Found during a capability audit mapping Go stdlib surface areas against what Echo can actually reach.

## Decision: make the pick in the harness at startup, not in the model **Decided by Kai, 2026-08-17, recorded by Darren (director seat).** ### The problem this issue would otherwise hit This issue asks Deep to pick 1 personality and 3 personal preferences to emphasize on container start. Implemented the obvious way, that is the model choosing, and **the model has no randomness**. There is no random tool anywhere in the surface, and a language model asked to pick at random does not pick uniformly or unpredictably. It has strong favourites, and it will have the same ones every rollout. So the naive version produces a feature that looks varied in review and is close to constant in production, which is the worst outcome available: nobody notices it is broken. ### The choice The selection happens in harness code at container start, where `crypto/rand` and `math/rand` are ordinary Go and genuinely available. The chosen personality and preferences are then injected as facts the model is told, rather than a decision the model makes. ### Why this is better than a random tool * It is reproducible. Log the seed and the rollout's persona is explainable after the fact, which matters the first time someone asks why Deep was odd on Tuesday. * It adds nothing to the tool array, which #859 shows is already expensive, since every skill and tool description is concatenated into the prompt at boot and the skillpack is 79% of Echo's prompt. * It happens once per rollout rather than once per turn, matching what this issue actually asks for. ### What this forecloses A general random tool on the model surface. Not chosen here. If a later feature needs a fair pick **during** a turn rather than at startup, that is a different issue and this decision does not settle it. ### Note for the wider surface The absence of randomness is not recorded anywhere else and it was found by audit rather than by failure. Anything else that wants a genuine unpredictable or uniform choice has the same problem and the same answer: do it in the harness. Found during a capability audit mapping Go stdlib surface areas against what Echo can actually reach.

coilyco-ops added

and removed

labels

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

coilyco-ops referenced this issue

2026-08-23 01:28:03 +00:00

Curated web-culture skill pack: giphy, tenor, imgur, knowyourmeme, xkcd #1029