Member Junction
    Preparing search index...

    Angular DI service for conversation-level agent orchestration.

    After PR 2 of the conversations-runtime extraction, the core processMessage flow and the conversation-manager-agent resolution are delegated to @memberjunction/conversations-runtime. This service is primarily a shim for those operations PLUS the holder of the helpers that haven't been ported yet:

    • invokeSubAgent(...) — used by Sage's routing decisions in message-input.component.
    • checkAgentContinuityIntent(...) — fast intent classification when the user replies to a previous-agent thread.
    • FindConfigurationPresetForAgent(...) — locates an agent's preset from prior

    in the conversation.

    • clearSession(...) — per-conversation session-id bookkeeping.

    These can move to the runtime in a follow-up; they aren't strictly needed to invoke an agent end-to-end and stay here so the shim has zero behavior difference vs. the original.

    Index

    Constructors

    Properties

    isProcessing$: Observable<boolean>

    Observable indicating if the ambient agent is currently processing — delegated to the runtime's AgentRunner.

    Accessors

    Methods

    • Configuration preset an agent was pinned to by a previous @mention in this conversation.

      Resolved by QUERY, not by scanning the display array. The pinning @mention is normally the FIRST message of an exchange and everything after it is follow-up, so it is the message most likely to fall below the loaded transcript window — and undefined is a legal value for configurationPresetId, so the miss is silent. The visible consequence is a run executed under the default configuration (a different model tier) instead of the one the user explicitly chose, with a plausible-looking result and no error.

      There is no column to filter on: the preset lives inside the message body as a JSON mention blob (@{"type":"agent","id":"…","configId":"…"}). So SQL narrows and the parser decides — both configId and the agent id appear verbatim in that blob, which makes the two LIKEs a tight prefilter, and parseMentions is what actually confirms a match.

      Parameters

      • conversationId: string
      • agentId: string

      Returns Promise<string | undefined>

    • Newest OUTPUT artifact version an agent produced in this conversation — resolved by QUERY, not by scanning the display array.

      The array scan this replaces was correct only while conversationHistory held the whole conversation. Under transcript windowing it holds one page, so the scan silently returns null for any artifact below the window's oldest row — exactly the long "modify this again" exchanges where payload continuity matters most. A null payload is a LEGAL agent input, so the failure is silent: the agent regenerates from scratch instead of modifying.

      One round trip. The subquery walks details -> Output junctions, and versions carry __mj_CreatedAt, so "newest" is expressible without joining back for Sequence.

      Parameters

      • conversationId: string
      • agentId: string

      Returns Promise<AgentPayloadSource | null>

    • Invoke a sub-agent based on Sage Agent's payload. This is called when Sage decides to delegate to a specialist agent.

      Stays on the Angular shim because it directly uses AgentClientService. Could move to the runtime in a follow-up if needed.

      Parameters

      • agentName: string
      • conversationId: string
      • message: MJConversationDetailEntity
      • conversationHistory: MJConversationDetailEntity[]
      • reasoning: string
      • conversationDetailId: string
      • Optionalpayload: Record<string, unknown> | null
      • OptionalonProgress: AgentExecutionProgressCallback
      • OptionalsourceArtifactId: string
      • OptionalsourceArtifactVersionId: string
      • OptionalagentConfigurationPresetId: string
      • OptionalappContext: Record<string, unknown> | null
      • OptionalplanMode: boolean
      • OptionalrequestedSkillIDs: string[]

      Returns Promise<ExecuteAgentResult | null>