Add MOIM (Minus One Info Message) for automatic context injection (TODO list and current time) #4833

tlongwell-block · 2025-09-25T20:14:27Z

Implements ephemeral context injection at the provider boundary to automatically include timestamp and TODO content in LLM context without modifying conversation history.

Problem

Previously, accessing TODO content required explicit todo__read tool calls, cluttering conversation history and consuming tokens. Timestamps were injected via template variables in system prompts, creating inconsistency across different prompt variants and preventing effective prompt caching.

Solution

MOIM (Minus One Info Message) injects a synthetic user message at approximately position -1 during provider calls. This message contains:

Current timestamp (always)
TODO content from session metadata (when available)

The injection happens in reply_parts.rs at the provider boundary, ensuring the message is never persisted to storage or returned in conversation history.

Architecture Benefits

Zero changes to core data structures (Message, Conversation)
No persistence layer modifications
Clean module boundaries
No impact on existing sessions or conversation replay

Testing

Comprehensive test coverage in crates/goose/tests/moim_tests.rs with proper test isolation using serial_test for tests that modify environment variables.

Migration

Removed todo__read tool (breaking change for recipes using it)
Updated todo__write description to reflect automatic availability
System prompts now receive timestamp via MOIM instead of template variables

DOsinga

left some preliminary comments. I think we should do something like this, but we need a structure that allows any platform tool this sort of thing. see: #4868 and the relevant discussion

crates/goose/src/agents/moim.rs

DOsinga · 2025-09-29T14:21:56Z

crates/goose-cli/src/scenario_tests/scenarios.rs

+    #[serial]
    async fn test_what_is_your_name() -> Result<()> {
-        run_scenario(
+        std::env::set_var("GOOSE_MOIM_ENABLED", "false");


don't set environment variables in tests like this; if they fail you now changed the settings for the next test. also if you are going to add this to all run_scenario, maybe handle this there?

I have the tests in serial now. I set the env var at the top of the test and unset at the bottom. It won't effect other tests that way

I think you're right that I could get the same effect by un/setting it in run_scenario(), but still making sure that everything that calls run_scenario() is serial

The reason I didn't is just because I can't internally guarantee that run_scenario will be in serial, hence it would be possible for an environment race condition to occur if called by a non-serial test

DOsinga · 2025-09-29T14:24:03Z

crates/goose/src/agents/reply_parts.rs


+        // Inject MOIM (timestamp + TODO content) if enabled
+        let messages_for_provider =
+            super::moim::inject_moim_if_enabled(messages_for_provider, session).await;


you should do this in agent.reply. there you can stick it into the block that already checks for session and make session non optional

I put it in stream_response_from_provider because I wanted it to be at the very, very edge of the shared inference execution path. This is the last point on that execution path that doesn't split between different providers

This makes reasoning about it much easier. There's no chance to be written to a session file, be compacted, etc, etc

As far as session optionality goes: it should 100% be required, but we can't do it yet. Once recipes/subagents/scheduler are on Agent Manager, they will have real sessions.

But, until then, stream_response_from_provider will be called without a session when dealing with recipes/subagents

Seems like the dependency is there from how the TODO stool stores its state over actually needing the session.

Yes. Instead of passing the session to inject_moim_if_enabled, I could pass TodoState::from_extension_data directly? It just ended up looking cleaner this way

Ah, no, lets keep passing the session in because we'll probably want to add more to moim from the session metadata later at some point. And its neater

crates/goose/src/prompts/system.md

tlongwell-block · 2025-09-29T14:57:04Z

left some preliminary comments. I think we should do something like this, but we need a structure that allows any platform tool this sort of thing. see: #4868 and the relevant discussion

Agree, yes. I think adding to build_moim_content() is the way to go here since there will probably be formatting and helpers involved when moving platform tool content from its storage into the MOIM (ie an array of sources is probably not sufficient, so using the build function is probably the best way forward)

# Conflicts: # crates/goose/src/prompts/subagent_system.md # crates/goose/src/prompts/system_gpt_4.1.md

katzdave · 2025-10-01T16:17:22Z

crates/goose/src/agents/moim.rs

+use crate::session::SessionManager;
+use chrono::Local;
+
+async fn build_moim_content(session: &Option<SessionConfig>) -> Option<String> {


I'd really like to see this as something the tool itself can define rather than a specific global place.

I talked about my thinking in a reply above:

"... I think adding to build_moim_content() is the way to go here since there will probably be formatting and helpers involved when moving platform tool content from its storage into the MOIM (ie an array of sources is probably not sufficient, so using the build function is probably the best way forward)"

Having each tool register itself to a moim system would work, too, but we might still want to format how they fit together, which requires a global function like this one

also, this global function allows us to put data in the moim that isn't related to a tool. Like the timestamp here. This could also be environment information or other non-tool context that we find useful for the agent

in light of the latest infra changes here's my proposal:

add a method to the platform extension type get_moim() and implement that for todo

add a method to extension_manager get_moim that goes through its platform extensions and collects them and then adds the current time

call this method from reply_internal (yeah, I know that is scary)

Working in #5027

katzdave · 2025-10-01T16:22:00Z

crates/goose/src/agents/reply_parts.rs


+        // Inject MOIM (timestamp + TODO content) if enabled
+        let messages_for_provider =
+            super::moim::inject_moim_if_enabled(messages_for_provider, session).await;


Seems like the dependency is there from how the TODO stool stores its state over actually needing the session.

tlongwell-block · 2025-10-06T16:37:56Z

#5027

tlongwell-block marked this pull request as ready for review September 26, 2025 18:08

DOsinga reviewed Sep 29, 2025

View reviewed changes

tlongwell-block force-pushed the moim branch 2 times, most recently from 117dee3 to af70b3b Compare September 29, 2025 18:26

tlongwell-block added 16 commits September 29, 2025 14:37

Initial MOIM work

d619a6e

actually add moim.rs

0c2f8f8

move tests. better tests

6b98395

fix tests, remove time from system prompts

9f3ed06

# Conflicts: # crates/goose/src/prompts/subagent_system.md # crates/goose/src/prompts/system_gpt_4.1.md

update insertion point logic and tests

c4b9ef8

less trivial tests

632936b

serial test

57d130e

comments around why serial is required

6879b5e

remove comments

d78164f

this is a bad joke

d5e1b98

testing is hard. Use SessionManager

7ba5141

recorded data tests are hard

1297c94

changes per review

56fd710

instruction for todo

6e1ddb9

deps

61739c3

deps are hard

1f7f5cf

tlongwell-block force-pushed the moim branch from af70b3b to 1f7f5cf Compare September 29, 2025 18:39

fmt

d220120

katzdave reviewed Oct 1, 2025

View reviewed changes

tlongwell-block closed this Oct 6, 2025

Add MOIM (Minus One Info Message) for automatic context injection (TODO list and current time) #4833

Add MOIM (Minus One Info Message) for automatic context injection (TODO list and current time) #4833

Uh oh!

Conversation

tlongwell-block commented Sep 25, 2025

Uh oh!

DOsinga left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tlongwell-block Sep 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tlongwell-block Sep 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

tlongwell-block commented Sep 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tlongwell-block commented Oct 6, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

tlongwell-block Sep 29, 2025 •

edited

Loading

tlongwell-block Sep 29, 2025 •

edited

Loading

tlongwell-block commented Sep 29, 2025 •

edited

Loading