Protected_JSON validator instance for cleaning and validating responses
Static ReadonlyCURRENT_Common placeholder for current payload injection
Determines if loop results should be injected as a temporary user message before the next prompt execution (for LLM reasoning).
Default: true (most agent types benefit from seeing loop results) Flow agents override to false (deterministic path navigation, no LLM)
true to inject results as message, false to skip
Indicates whether this agent type requires agent-level prompts (AI Agent Prompts relationship).
Some agent types (like Flow) use step-level prompts exclusively and don't need agent-level prompts. Other agent types (like Loop) require agent-level prompts for their main reasoning loop.
Default: true (most agent types require agent-level prompts)
True if agent-level prompts are required, false if optional
The Loop type reads tool calls back as Actions steps (§8.1), so its Actions may be declared as tools.
OptionalAfterCalled after each loop iteration completes to process results.
Flow agents use this to apply ActionOutputMapping and update payload. Loop agents typically don't need this (just collect results).
Results from this iteration
Modified payload or null for default behavior (just collect result)
OptionalBeforeCalled before each loop iteration to prepare parameters and payload.
Loop agents use this to resolve template variables ("item.email"). Flow agents typically don't need this (params already resolved).
Current iteration context
Modified context or null for default behavior
ProtectedcreateProtectedCreates a standardized next step object with common defaults
The payload type
The step type
Optionaloptions: Partial<BaseAgentNextStep<P>>Additional options to merge
The next step object
ProtectedcreateProtectedCreates a retry step with a standardized error message
The payload type
The error message
Optionaloptions: Partial<BaseAgentNextStep<P>>Additional options
Retry step
ProtectedcreateProtectedCreates a success step with optional payload changes
The payload type
Optionaloptions: Partial<BaseAgentNextStep<P>>Success options
Success step
Determines the initial step for loop agent types.
Loop agents always start with a prompt execution to determine the initial actions.
The full execution parameters
Always returns null to use default behavior
AbstractDetermineAnalyzes the output from prompt execution to determine the next step.
This method is called after the hierarchical prompts have been executed and should parse the LLM's response to determine what the agent should do next. The implementation depends on the specific agent type's logic and the format of output expected from its system prompt.
Result from prompt execution (null for non-prompt steps)
The full execution parameters including agent and context
OptionalnativeToolBindings: ReadonlyMap<string, NativeToolBinding>The determined next step and optional return value
public async DetermineNextStep(): Promise<BaseAgentNextStep> {
// Implementation might parse JSON output from LLM
const response = JSON.parse(this.lastExecutionResult);
if (response.taskComplete) {
return { step: 'success', payload: response.payload };
} else if (response.needsSubAgent) {
return { step: 'subagent', payload: response.subAgentConfig };
} else {
return { step: 'action', payload: response.nextAction };
}
}
Provides agent-type-specific guidance for configuration errors related to missing prompts. This allows each agent type to give contextual help based on its architecture.
Default implementation provides generic guidance. Agent types should override to provide specific instructions relevant to their configuration requirements.
Configuration guidance specific to this agent type
Gets the prompt to use for a specific step. Loop agents always use the default prompt from configuration.
The execution parameters (unused)
The loaded agent configuration
OptionalpreviousDecision: BaseAgentNextStep<P>The previous step decision (unused)
Returns config.childPrompt
Determines how to handle Success or Failed steps when no explicit termination is requested.
This allows agent types to control their own fallback behavior:
Default implementation returns null, which causes base-agent to fall back to prompt execution if prompts are configured. Agent types can override this to provide custom behavior.
The Success or Failed step that needs fallback handling
The loaded agent configuration
The execution parameters
The current payload
Agent type's state
Custom step to execute, or null for default behavior
This method allows each agent type to initialize its agent-run-specific state package as required. Not all agent types require this and are able to live off just the current payload or other properties passed to them to DetermineNextStep(), but some require more complex internal state tracking.
the agent execution params
the fully initialized initial agent-type state
Injects a payload into the prompt parameters. For LoopAgentType, this could be used to inject previous loop results or context.
The payload to inject
The prompt parameters to update
Agent identification info (unused by LoopAgentType)
ProtectedisProtectedValidates that the response conforms to the expected LoopAgentResponse structure.
True if the response is valid, false otherwise
ProtectednextTurns native tool calls on the turn into an Actions step, or returns null when there were
none (the envelope path).
Resolution is by the reverse map rather than by re-sanitizing names, because sanitization is lossy: two Action names can collapse to one tool name, which buildActionToolSet rejects at build time precisely so this lookup can be exact.
A call naming a tool that was never declared is a Retry, not a silent drop. Cerebras is documented to do this, measured at roughly one forced call in six, so the loop has to be able to say "that tool does not exist" rather than appear to hang.
Optionalbindings: ReadonlyMap<string, NativeToolBinding>ProtectedparsePost-processes the result of action execution.
This method is called by BaseAgent after action(s) have been executed. Agent types can override this method to perform custom processing of action results, such as mapping output parameters to the payload or storing results in agent-specific context.
The results from action execution
The actions that were executed
The current payload
The current step being executed
Optional payload change request
Post-processes the result of sub-agent execution.
This method is called by BaseAgent after a sub-agent has been executed. Agent types can override this method to perform custom processing of sub-agent results, such as extracting specific data from the sub-agent's payload or updating context.
The result from sub-agent execution
The sub-agent request that was executed
The current payload
The current step being executed
Optional payload change request
Pre-processes action parameters to resolve conversation references.
Loop agents get action parameters directly from the LLM's JSON response. This method resolves any "conversation.*" references in those parameters before the actions are executed.
The actions that will be executed (modified in place)
The current payload
The agent type state
The current step being executed
Optionalparams: ExecuteAgentParams<P>The execution parameters with conversation messages
Actions are modified in place
Pre-processes steps for loop agent types.
Loop agents use the default next step behavior which executes the prompt again.
The full execution parameters
The step that needs to be preprocessed
Always returns null to use default behavior
ProtectedstripRemoves a markdown code fence WRAPPING an entire response, if one is present.
Models fenced their JSON long before this existed — the retry feedback in LoopAgentType
already tells them not to — but a retry costs a whole turn to recover something we already
received intact. Observed with an external harness: the response was perfectly valid
{"taskComplete": true, ...} inside a ```json fence, rejected by JSON.parse, and the identical
answer came back on the retry. Half the latency and half the cost of that run bought nothing.
It strips ONLY the first line and the trailing fence, never anything interior. A response's
own payload frequently contains fenced code — the case that prompted this had ```haskell blocks
inside its message string — so a global strip would corrupt exactly the responses it was
meant to rescue.
The stripped text is only used if it PARSES. On failure the original is returned untouched, so the outcome is either "an unparseable response became parseable" or "no change" — never a previously-good response turned bad. Deterministic, no model call, microseconds.
Protected StaticgetProtectedInstantiates an agent type class using a specific driver class name.
This method is used when an individual agent has its own DriverClass override, allowing for specialized implementations per agent instance.
The driver class name to instantiate
Instance of the agent type class
Protected StaticgetProtectedInstantiates the appropriate agent type class based on the agent type entity.
This method uses the MemberJunction class factory to dynamically instantiate agent type classes. It uses the DriverClass field. If DriverClass is not specified it throws an error.
The agent type entity to instantiate
Instance of the agent type class
StaticGetHelper method that retrieves an instance of the agent type based on the provided agent type entity.
This method uses the ClassFactory to create an instance of the agent type class specified in the DriverClass field of the agent type entity. If the DriverClass is not specified, it throws an error.
The agent type entity to instantiate
An instance of the agent type class
The
Harnessagent type — an MJ agent whose reasoning is supplied by an external agent harness.Why this subclasses LoopAgentType rather than BaseAgentType
A harness turn is protocol-identical to a Loop agent's prompt iteration. The harness reasons, then ends its turn by emitting the same next-step JSON envelope a Loop model emits. Everything downstream of that decision —
validateActionsNextStep,validateSubAgentNextStep, per-actionMaxExecutionsPerRun, skill activation gates, plan-mode blocking,PayloadManagerpath ACLs,checkExecutionGuardrailsbetween iterations, run-step recording — is already written and already correct.Inheriting
DetermineNextStepwholesale is therefore not a shortcut, it is the entire point: it means a harness agent runs inside MJ's enforcement stack rather than beside it, with no second authority path to audit. An independent implementation would have to re-derive every one of those guarantees and would drift from the Loop path the first time either changed.The dual-registry key
ClassFactory registrations are namespaced per base class, so the string
'HarnessAgentType'is registered TWICE against different roots:· here, under
BaseAgentType— resolved byBaseAgentType.GetAgentTypeInstancefromAIAgentType.DriverClass, giving the turn-protocol behaviour; · in HarnessAgentBase, underBaseAgent— resolved byAgentRunnerfrom the same column, giving the execution driver that substitutes a harness turn for a prompt call.That is the mechanism working as designed rather than an overload:
AgentRunneralready treats the agent type'sDriverClassas aBaseAgentkey and falls back to plainBaseAgentwhen the key is unregistered there, which is exactly why every Loop agent gets the base execution class today. Registering both makes one metadata column select both halves.The subtlety is worth stating because it is invisible at each registration site on its own: seeing only this file, a reader would reasonably assume
'HarnessAgentType'names one class.