Member Junction
    Preparing search index...

    Process-wide cache of the most recent settled root run's Tool-step results per conversation + agent, keeping the prior-turn carry-forward check off the database on the agent hot path.

    The completing run is the one source that already holds this data with zero I/O: BaseAgent.finalizeAgentRun projects its in-memory Steps into CarryForwardStepRecords and stores them here — including an empty array when the run made no tool calls, so tool-free conversations (the common case) skip the lookup queries entirely on every subsequent turn. loadPriorTurnToolResultSteps consults this cache first and only falls back to its RunView pair on a miss.

    Consistency contract — same row predicate as the DB path (single-sourced in BaseAgent.carryForwardPredicate + BaseAgent.settledRunStatuses):

    • Only runs that settle as Completed OR AwaitingFeedback (the normal chat-turn ending) are stored, so a failed run leaves the previous settled run's entry in place, just as the DB query would return it.
    • Entries are keyed by conversation AND agent, mirroring the DB path's AgentID filter — in a multi-agent conversation, agent B must never inherit agent A's results labeled "your previous turn".
    • Values are the raw completed-Tool-step OutputData projections; eligibility is still decided downstream by BuildPriorTurnToolResultsMessage via toolFamily, identical for cached and DB-loaded records.
    • Two benign same-node edges where in-memory truth wins over what the DB fallback would return: a Tool step whose fire-and-forget INSERT failed is still published (the result genuinely existed; the DB would omit the lost row), and when two root runs of the same agent complete concurrently for one conversation the LAST-completed run's projection is kept here while the DB orders by creation time. Both only affect which optimization payload gets carried one turn forward.

    Multi-node tradeoff (accepted by design): when a conversation's next turn lands on a different server than the one that completed the prior run, this node either misses (falls back to the DB — exact) or, at worst, holds an entry one completed run stale and injects the previous-but-one turn's results. Carry-forward is a contained optimization (errors never break the run, injected messages expire after 2 turns), the TTL bounds the staleness window, and each node self-heals on its next completed run for that conversation — so the fallback keeps the default single-node deployment exact while multi-node degrades gracefully rather than paying the queries every turn.

    Hierarchy (View Summary)

    Index

    Constructors

    Accessors

    • get GlobalKey(): string

      Returns string

    Methods

    • The Global Object Store is a place to store global objects that need to be shared across the application. Depending on the execution environment, this could be the window object in a browser, or the global object in a node environment, or something else in other contexts. The key here is that in some cases static variables are not truly shared because it is possible that a given class might have copies of its code in multiple paths in a deployed application. This approach ensures that no matter how many code copies might exist, there is only one instance of the object in question by using the Global Object Store.

      Returns GlobalObjectStore

    • Returns the singleton instance of the class. If the instance does not exist, it is created and stored in the Global Object Store. If className is provided it will be used as part of the key in the Global Object Store, otherwise the actual class name will be used. NOTE: the class name used by default is the lowest level of the object hierarchy, so if you have a class that extends another class, the lowest level class name will be used.

      Type Parameters

      Parameters

      • this: new () => T
      • OptionalclassName: string

      Returns T