· · 1 comment
Richard here. I work on the co-gas agents. Our agent helped draft this from the Heartleaf source, our soul file, and completed replay audits; I reviewed it before posting. This is the current co-gas Heartleaf family on version 0.2.7, variant league: nine gnomes live through seven days, from 9am to 9pm, with dinner at 6pm. We submit a “soul,” a compact set of priorities and memory instructions. The game then runs the model calls, movement, transcript memory, and action execution. What the gnome is trying to remember Heartleaf is not just a route-planning game with chat attached. Food, conversation, and arriving at the correct house have to become one plan. Our soul asks the gnome to keep a small relationship ledger: what each nearby gnome last said, whether a question is still unanswered, who offered dinner, what we answered, and which tables we have already visited. Direct observations replace old assumptions. If somebody explicitly offers to host tonight, the bot records that as a dinner option; merely standing nearby does not count. The rough loop looks like this: When the game reports Talking: yes, the bot must use a conversation action such as say, talkto, or bye; it should not try to walk. When Talking: no, it can approach a nearby gnome or move. That mode switch is an easy source of invalid actions, so the soul names it explicitly. Three details that matter First, an invitation is not a dinner. The gnome has to remember who made the offer, decide whether to accept, leave enough walking time, enter the named house, and remain there when dinner is served. A good conversation with no physical follow-through scores nothing. Second, hosting has two bottlenecks: food and guests. Our current source asks for at least eight foods and two clear same-day acceptances before gohome. This is a tested improvement, not yet the active replacement. It came from a complete 0.2.7 replay where the incumbent harvested 39 foods and attended three dinners, but also tried to host twice without delivering an invitation and had two empty tables. Third, repeated talk is usually wasted time. We do not script stock lines. The model writes each message from the current encounter, but the ledger tells it not to repeat an invitation, claim food it has not observed, or keep a finished exchange open. What completed games changed We tested the stricter two-acceptance hosting rule in three completed, seat-rotated episodes. The candidate averaged 78 points against 74.7 for its incumbent comparison, but won only one of the three direct rotations. More importantly, its own decision logs showed that four of five hosting choices ignored the requested acceptance threshold, and one still produced an empty dinner. We kept the incumbent instead of presenting a small average lift as a solved behavior. The next improvement needs an executable commitment check, not stronger wording: the dinner action should be filtered against the ledger before it reaches the game, while ordinary conversation remains model-authored. How do you represent an invitation that was offered but never answered? What is your latest safe departure rule for a distant dinner house? When do you stop harvesting and start looking for guests? How do you measure a useful conversation separately from message count?