What is the valuable information that needs to be persisted for AgentProcess

[smilyanovr]

I am looking for a way to implement an internal AgentProcessRepository which stores the agent process in a database. I need the ability to suspend and resume an agent process, though resume might be performed on a different JVM instance.

What would be the minimal information that needs to be persisted in order to resume a process?

[johnsonr]

Mainly the contents of the blackboard. You would also need to persist some of the system state eg current status. Whatever you needed to instantiate a SimpleAgentProcess.

[smilyanovr]

Thanks for the feedback! Here are the steps I made in order to make this work:

1. Added an internal implementation for AgentProcessRepository and ContextRepository.
2. Added a listener for AgentProcessEvent events
3. All events will save the agent process
4. ObjectAddedEvent and ObjectBoundEvent will update the context additionally
5. I created my own EmbabelContext which implements Context interface. I had to do this because I need to add @JsonTypeInfo for the objects field in order to serialize my context as JSON with information for the types. Otherwise the type information is lost after trying the deserialize the context and all objects become a Map of properties. This whole thing seems to be needed during the computation of the world state after agent process is restored from the database. (BlackboardWorldStateDeterminer.determineWorldState).

The db model for dealing with agent process and backboard looks like this:

CREATE TABLE agent_context
(
    id                  VARCHAR(50)  NOT NULL,
    context        JSON         NOT NULL,
    created_at  INT UNSIGNED NOT NULL,
    updated_at INT UNSIGNED NOT NULL,
    PRIMARY KEY (id)
) 

CREATE TABLE agent_process
(
    id                   VARCHAR(50)  NOT NULL,
    agent_name VARCHAR(100) NOT NULL,
    parent_id      VARCHAR(50) DEFAULT NULL,
    context_id    VARCHAR(50) DEFAULT NULL,
    status            VARCHAR(100) NOT NULL,
    created_at    INT UNSIGNED NOT NULL,
    updated_at   INT UNSIGNED NOT NULL,
    PRIMARY KEY (id),
    FOREIGN KEY (parent_id) REFERENCES agent_process (id),
    FOREIGN KEY (context_id) REFERENCES agent_context (id)
) 

There are couple of things which I had to workaround in order to add my own AgentProcessRepository. The instantiation of SimpleAgentProcess requires access to AgentPlatform. On the other hand DefaultAgentPlatform also uses internally the repository which leads to cyclic dependencies. Thus I ended up having a wrapper for the AgentPlatform interface with Lazy annotation in order to postpone beans initialization.

@johnsonr do you see any major issues with my approach? Maybe I am still missing some implementation details in Embabel and some of the things I did might be done in a simpler way. Will appreciate your feedback.

[johnsonr]

This seems like the right direction.

[smilyanovr]

Sorry for asking a completely different question on this issue.

Now I am looking into this code in Embabel within PerGoalToolCallbackFactory:

    /**
     * Create tool callbacks for the given goal.
     * There will be one tool callback for each starting input type of the goal.
     */
    fun toolsForGoal(
        goal: Goal,
        listeners: List<AgenticEventListener>,
    ): List<GoalToolCallback<*>> {
        val goalName = goal.export.name ?: goalToolNamingStrategy.nameForGoal(goal)
        return goal.export.startingInputTypes.map { inputType ->
            GoalToolCallback(
                autonomy = autonomy,
                name = "${inputType.simpleName}_$goalName",
                description = goal.description,
                goal = goal,
                inputType = inputType,
                listeners = listeners,
                textCommunicator = textCommunicator,
            )
        }
    }

I find the final tool name quite verbose since it includes always the input type class name. I would rather expect to honor the tool name as it was defiend in the Export itself. Do you think this is reasonable? I would be happy to contribute with code changes.
Also please let me know if you prefer to open a new discussion because this is not really related to the initial question.

[johnsonr]

I think would be fine. I agree that tool names can be excessively verbose. This can actually confuse small models and uses context size.

Happy to have a PR if this works.

[smilyanovr]

Thanks, I will try to find some time this week and prepare a PR.