Evolving Mode

[Stuckya]

I am an early adopter of embabel-agent and I primarily use the Utility AI planner. My service is event-driven.

I've found Embabel to have good support for invocation-time agent and goal selection through Autonomy and scoped invocation through UtilityInvocation and SupervisorInvocation. But, event-driven domains need the same kind of public invocation shape for long-lived processes whose objectives can change at runtime.

The proposed Evolving Mode lets a running process update its active goals, without mutating the agent’s declared goals. I believe we could achieve this without introducing a new PlannerType or repeatedly invoking Open/Supervisor mode.

I believe Evolving Mode should compose with GOAP, Utility, and Hybrid planners by changing the effective planning system visible to a process on the next planning tick.

I think best when looking at concrete examples, so below is what I'm thinking.

LLM invoked shape:

EvolvingInvocation.on(agentPlatform)
    .withScope(AgentScopeBuilder.fromInstances(
        navigationCapabilities,
        storageCapabilities,
        collectionCapabilities,
        hazardResponseCapabilities
    ))
    .withObjectiveAuthor(llmObjectiveAuthor)
    .run(new UserInput("Collect samples in Zone A until 500 samples are stored"));

Deterministic shape:

EvolvingInvocation.on(agentPlatform)
    .withScope(scope)
    .withEvolution(collectSamplesUntilEvolution)
    .run(new CollectSamplesUntil(
        Zone.A,
        SamplesStored.atLeast(500)
    ));

What about recursive Open Mode?

IMO, Open/Supervisor mode is still valuable for deliberation, interpretation, and discovery. But it should not be repeatedly invoked as the control loop for event-driven domains. This preserves the useful part of Open mode without making nondeterministic, expensive LLM orchestration the response to every external state change. This approach feels very embabel oriented.

Blackboard ingress

Additionally, I've found the embabel-agent API and docs to currently lack good guidance on how an event-driven system should interact with the blackboard.

For event-driven domains, I want a boring, typed, deterministic way to say:

• this external event happened
• this fact is now visible to the running process
• this fact may activate, expire, or reprioritize runtime objectives
• the planner should see the update on the next planning tick

Something like:

process.blackboardIngress()
    .publish(new HazardDetected(...));

The exact API is less important to me than the contract: external events should enter through a sanctioned ingress point, become visible at planning ticks, and avoid re-triggering the same runtime objective forever unless explicitly stated.

I have a throwaway POC/spec exploring this shape, but wanted to discuss the direction here first.

[igordayen]

@Stuckya - thanks for the write-up.
Quote from README
"Evolving mode: Where the platform can work with multiple goals in the same process and modify a running process to add further goals and agents. For example, an action can realize that it has become important to achieve additional goals."

My reading is that action is capable of mutating the list of actions, and tagging actions as "achievable goals". I presume that conditions can be mutated too.
This interpretation contradicts your statement "The proposed Evolving Mode lets a running process update its active goals, without mutating the agent’s declared goals", if I'm not mistaken.
Also, perhaps event-driven additional observability could be more in-line with newly updated observation capabilities.

[Stuckya]

I see what you mean.

In my mind "without mutating the agent’s declared goals" means we treat user's existing declared Agents as immutable. The running process can still add process-local runtime goals, but it does not rewrite the source agent metadata. That keeps declared behavior deterministic while still allowing the process to evolve.

Psuedocode:

EvolvingInvocation.on(agentPlatform)
    .withScope(scope)
    .withEvolution(evolution -> evolution
        .onFact(BufferFlushNeeded.class)
            .addRuntimeGoal(BufferFlushed.class)
            .includeFact(BufferFlushNeeded.class)
            .resumable()

In my proposal, EvolvingInvocation composes reusable capabilities / agents. Process ingress turns external events into typed facts at planning ticks, Embabel actions derive domain facts from those events, and the evolving process updates its active runtime goals without mutating declared agent goals.

What do you think?

[Stuckya]

Maybe we could say something like:

• Declared capabilities == immutable @Agent and @EmbabelComponent actions and goals.
• Runtime facts == event-driven state entering the process at planning ticks.
• Runtime goals == process-local goals added by an evolution policy.

[igordayen]

Maybe we could say something like:

• Declared capabilities == immutable @Agent and @EmbabelComponent actions and goals. ==> agree
• Runtime goals == process-local goals added by an evolution policy.. ==> agree

As for run-time facts / events and sourcing domain entities out of events, would be helpful if you could elaborate more.

@Stuckya - I'm thinking more about an incremental approach: are run-time facts tightly coupled with Evolving mode? Thanks

[igordayen]

@azanux - could you please assess the impact on observability framework. thanks

[azanux]

@igordayen

The concept is very interesting and would be of great value.

Regarding observability, here is my take.

Observability was already built for processes that go idle and wake up again:
every wake-up is recorded as one unit of work, and all the wake-ups of the same process are grouped under one stable
session id (conversation.id). The Evolving feature is the same shape, except the trigger is
an external event instead of a user message - so the session/turn/idle machinery needs no rework.

• One decision worth settling up front: when a process is woken by an external event, how does that wake-up stay attached to the right session? Today a resume is an explicit run() we control. With ingress, if we do nothing, each wake-up shows up as a
  detached, orphan trace with no link to the process it belongs to.

---

What the Evolving implementation should respect

1. A wake-up must continue the existing process (and reuse its session id), not start a fresh disconnected one.)
2. Keep turn boundaries clean - each wake-up has a clear start and end.
3. Always close cleanly, even on error.
4. Give runtime goals a lifecycle (they can be added and expire) and clean up per-turn state at the end of each turn, not at termination - an event-driven process may run forever.

This should normally be good to go.

[igordayen]

Thanks, @azanux. I was thinking about a pub/sub JMS-like model, with multiple agent processes awaiting the event they subscribe to. Perhaps it could be a subject for separate discussion? Please feel free to open a discussion, and perhaps keep this one more focused on the "mutable" agent paradigm, "Evolving Mode Essentials".
Thanks

[azanux]

Thanks @igordayen, agreed. I think there are really three separate things here:

1. Evolving Mode itself (this thread): how a single running process changes its own goals while it runs - new facts come in, goals get added or dropped, and each tick it plans over declared + runtime goals.

2. Pub/sub (maybe a separate thread): this depends on whether @Stuckya wants a single event to wake several processes at once. If an event only ever goes to one known process, we probably don't need pub/sub - the blackboard ingress already delivers it point-to-point (like in his example). Pub/sub only earns its place for fan-out (one event → many agents), or when the publisher doesn't know who will consume. If that's the intent, I'm happy to open a separate thread and link back.

3. Observability: for Evolving Mode itself, the impact is small. It works like a chatbot waiting for a message: the process wakes up, starts a new turn, reconnects to the session via conversation.id, and records the event's data and source as span attributes - same as we already capture a chat message.
   The only genuinely new piece is linking a turn back to the span of the process that produced the event, in its own trace. That only matters when the producer is a separate traced process - i.e. the fan-out / pub-sub case. For a plain external event in a 1→1 flow, the cause is already in the same trace, so there's nothing extra to do.

So we can keep this thread on Evolving Mode, and open a pub/sub thread if that's the direction @Stuckya wants

Thanks!

[igordayen]

@azanux - well written, thanks!

[Stuckya]

I agree, this is a good take.

Right now, my use case, only ever needs to ingress facts to 1 known process. With that said, I agree, let's keep this thread on Evolving Mode essentials; pub/sub can be its own discussion if and when someone brings a real fan-out use-case.

@igordayen, earlier you asked:

I'm thinking more about an incremental approach: are run-time facts tightly coupled with Evolving mode?

Me too.

Internally-driven evolution probably doesn't need ingress for runtime facts. An action could produce a fact and the evolution policy maps that to a new runtime goal.

BUT, if we want external state to also drive evolution (my use-case), we need a sanctioned path for external runtime fact ingress. External fact ingress benefits any long-lived process.

User's external event -> runtime fact ingress -> runtime facts -> evolution policy -> runtime goals -> planner

So the dependency is one-directional. Ingress doesn't need Evolving Mode, but external-driven Evolving Mode needs ingress. That makes ingress the natural first increment IMO.

[igordayen]

@Stuckya - thank you.
Basically, Evolving Mode might evolve:) incrementally:

• phase 1 - internal triggers/events
• phase 2 - external triggers/events

Proper understanding?

[Stuckya]

Yep. I think they could be built in parallel too.

Only the fact source differs between phases, so the evolving "engine" is shared.

From here. I can write up a short spec with some of my thoughts. Gives us something a bit more concrete to discuss and then feed into CC or Codex for further exploration.

[igordayen]

Good call. Just keep in mind that 1.0.0 GA scope is closed (except bugs). As per process - please create an issue which then will be prioritized for the proper milestone. thank you

[Stuckya]

Thanks for the heads up. Post 1.0.0 is a fine target and I'll create an issue shortly.

[simeshev]

@Stuckya, would you mind sharing your use case, in practical terms?