MCP Example 3 - Loan Application Extended

This is the confirmation-first version of the loan flow built around the newer runtime behavior:

• CorrectionStep handles confirmation affirmations and in-place edits
• POST_DIALOGUE_ACT can override guarded dialogue-act output before interaction policy runs
• POST_SCHEMA_EXTRACTION moves the flow into confirmation once required data is complete
• PRE_AGENT_MCP delays MCP until the user explicitly confirms
• SET_INPUT_PARAM can mark confirmation runtime flags without extra Java code
• SET_DIALOGUE_ACT can safely promote an LLM candidate act (for example EDIT) back into the final dialogue_act
• ConvEngineVerboseAdapter / ce_verbose can emit custom progress messages for the confirm-and-process path

This is the recommended state machine for the extended loan workflow:

IDLE -> ELIGIBILITY_GATE -> CONFIRMATION -> PROCESS_APPLICATION -> COMPLETED

Current demo seed gap

The current convengine-demo mcp_planner_seed.sql still scopes the loan planner and tools to ELIGIBILITY_GATE and closes directly to COMPLETED. It does not yet model CONFIRMATION and PROCESS_APPLICATION. This example shows the missing shape to add.

Flow summary

State flow

State	Purpose	What happens here
IDLE	Loan intake entry	Intent is recognized; rule moves into ELIGIBILITY_GATE.
ELIGIBILITY_GATE	Required field collection	Schema extraction collects customerId, requestedAmount, tenureMonths.
CONFIRMATION	User review	Show exact collected values; allow AFFIRM or EDIT.
PROCESS_APPLICATION	MCP execution	Planner runs credit -> fraud -> debt -> submit in sequence.
COMPLETED	Final answer	Derived response uses context.mcp.finalAnswer as the primary summary.

Chat + Trace

Turn 1 - User

Hi

Info

• Greeting classifier matches.
• Loan flow has not started yet.

Turn 1 - Assistant

intent: GREETINGstate: IDLE

Hi, how can I help you today?

{}

{
  "intent": "GREETING",
  "state": "IDLE"
}

Tables

• ce_intent_classifier (R)
• ce_response (R)
• ce_audit (W)

Info

• Normal greeting response.

Turn 2 - User

I need a loan for my customer

Info

• Loan classifier matches LOAN_APPLICATION.
• POST_AGENT_INTENT rules move the flow into ELIGIBILITY_GATE.

Turn 2 - Assistant

intent: LOAN_APPLICATIONstate: ELIGIBILITY_GATE

Please provide customerId, requestedAmount, and tenureMonths.

{}

{
  "intent": "LOAN_APPLICATION",
  "state": "ELIGIBILITY_GATE",
  "missing_fields": [
    "customerId",
    "requestedAmount",
    "tenureMonths"
  ]
}

Tables

• ce_rule (POST_AGENT_INTENT)
• ce_output_schema (R)
• ce_response (R)
• ce_prompt_template (R)
• ce_audit (W)

Info

• Schema is incomplete, so the engine asks only for missing required fields.

Turn 3 - User

customer id 1234, 35000, 24 months

Info

• Schema extraction fills all three required fields.
• POST_SCHEMA_EXTRACTION can now move the flow into CONFIRMATION.

Turn 3 - Assistant

intent: LOAN_APPLICATIONstate: CONFIRMATION

Please confirm: customerId 1234, requestedAmount 35000, tenureMonths 24. Proceed?

{}

{
  "state": "CONFIRMATION",
  "interaction_mode": "CONFIRM",
  "interaction_contract": {
    "allows": [
      "affirm",
      "edit",
      "reset"
    ],
    "expects": []
  }
}

Tables

• ce_output_schema (R)
• ce_rule (POST_SCHEMA_EXTRACTION)
• ce_response (R)
• ce_prompt_template (R)
• ce_audit (W)

Info

• Schema is complete.
• No MCP tools run yet because the flow stops at confirmation first.

Turn 4 - User

Ohh wait, I missed one zero. Change amount to 350000.

Info

• DialogueActStep should resolve EDIT.
• CorrectionStep patches only requestedAmount in place.

Turn 4 - Assistant

intent: LOAN_APPLICATIONstate: CONFIRMATION

Updated. Please confirm: customerId 1234, requestedAmount 350000, tenureMonths 24. Proceed?

{}

{
  "state": "CONFIRMATION",
  "correction_applied": true,
  "correction_target_field": "requestedAmount"
}

Tables

• ce_response (R)
• ce_prompt_template (R)
• ce_audit (W)
• ce_verbose (optional R)

Info

• Only the amount changes.
• The engine stays in CONFIRMATION and skips full schema re-extraction.

Turn 5 - User

Looks good, go ahead.

Info

• DialogueActStep resolves AFFIRM.
• CorrectionStep sets routing_decision=PROCEED_CONFIRMED.

Turn 5 - Internal MCP Loop

intent: LOAN_APPLICATIONstate: PROCESS_APPLICATION

Confirmation accepted. Starting loan processing. PRE_AGENT_MCP moves to PROCESS_APPLICATION. Planner executes credit -> fraud -> debt -> submit.

{}

{
  "state": "PROCESS_APPLICATION",
  "routing_decision": "PROCEED_CONFIRMED",
  "mcp": {
    "observations": [
      {
        "toolCode": "loan.credit.rating.check",
        "json": "{\"creditRating\":782}"
      },
      {
        "toolCode": "loan.credit.fraud.check",
        "json": "{\"flagged\":false}"
      },
      {
        "toolCode": "loan.debt.credit.summary",
        "json": "{\"dti\":0.31,\"availableCredit\":220000}"
      },
      {
        "toolCode": "loan.application.submit",
        "json": "{\"applicationId\":\"APP-90817\",\"status\":\"SUBMITTED\"}"
      }
    ]
  }
}

Tables

• ce_rule (PRE_AGENT_MCP)
• ce_mcp_planner (R)
• ce_mcp_tool (R)
• ce_audit (W)
• ce_verbose (optional R)

Info

• Tools are now scoped to PROCESS_APPLICATION.
• This is the missing step in the current demo seed.

Turn 5 - Final

intent: LOAN_APPLICATIONstate: COMPLETED

Loan application submitted successfully for customer 1234. Requested amount: 350000, tenure: 24 months. Credit rating passed, fraud check clear, debt profile acceptable. Application ID: APP-90817.

{}

{
  "state": "COMPLETED",
  "mcp": {
    "finalAnswer": "Loan application submitted successfully for customer 1234. Requested amount: 350000, tenure: 24 months. Application ID: APP-90817.",
    "lifecycle": {
      "phase": "POST_AGENT_MCP",
      "status": "ANSWER",
      "outcome": "ANSWERED",
      "finished": true
    }
  }
}

Tables

• ce_rule (POST_AGENT_MCP)
• ce_response (R)
• ce_prompt_template (R)
• ce_conversation (W)
• ce_audit (W)

Info

• POST_AGENT_MCP closes the flow only after context.mcp.finalAnswer exists.
• COMPLETED response derives from final MCP context.

Step Graph

Extended loan confirmation-first flow

IDLE -> ELIGIBILITY_GATE -> CONFIRMATION -> PROCESS_APPLICATION -> COMPLETED

Execution Steps

Press enter or space to select a node.You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel.

Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.

Step Detail

Schema extraction

SCHEMA_EXTRACTION

Collects customerId, requestedAmount, and tenureMonths using the ELIGIBILITY_GATE schema + prompt template.

Session Snapshot

• context.customerId
• context.requestedAmount
• context.tenureMonths
• schemaComplete

Tables Touched

• ce_output_schema (R)
• ce_prompt_template (SCHEMA_JSON)
• ce_audit (W)

Component Tables

Table usage by phase

Phase	Reads	Writes	Why it matters
Intent bootstrap	ce_intent_classifier, ce_rule	ce_audit	Classifier starts in IDLE; rules move into ELIGIBILITY_GATE.
Schema collection	ce_output_schema, ce_prompt_template, ce_response	ce_audit	Collect and ask only for missing fields.
Schema complete gate	ce_rule	ce_audit	POST_SCHEMA_EXTRACTION moves to CONFIRMATION and can set runtime flags.
Confirmation response	ce_response, ce_prompt_template	ce_audit	Shows exact collected values before any MCP call.
Correction path	session/context, optional ce_verbose	ce_audit	Patch only the changed field and stay in CONFIRMATION.
Pre-MCP gate	ce_rule	ce_audit	PRE_AGENT_MCP checks routing_decision and unlocks PROCESS_APPLICATION.
Planner + tools	ce_mcp_planner, ce_mcp_tool	ce_audit	Run the credit/fraud/debt/submit chain only after confirmation.
Post-MCP close	ce_rule	ce_audit	POST_AGENT_MCP moves PROCESS_APPLICATION -> COMPLETED.
Final response	ce_response, ce_prompt_template	ce_conversation, ce_audit	Return the final derived summary from context.mcp.finalAnswer.

What is missing from the current demo seed

Current seed	Missing piece	Needed for this example
Classifier starts LOAN_APPLICATION in ELIGIBILITY_GATE	No clean IDLE intake entry	Classifier starts in IDLE, then POST_AGENT_INTENT advances.
Planner scoped to ELIGIBILITY_GATE	Runs too early	Planner row should be scoped to PROCESS_APPLICATION.
Tools scoped to ELIGIBILITY_GATE	APIs can run before confirmation	Tool rows should be scoped to PROCESS_APPLICATION.
POST_AGENT_MCP closes ELIGIBILITY_GATE -> COMPLETED	No confirmation checkpoint	Add CONFIRMATION and PROCESS_APPLICATION phases in between.
No confirmation prompt row	No explicit user review step	Add CONFIRMATION TEXT prompt + response.
No PRE_AGENT_MCP confirmation rule	No confirm-before-run gate	Route only after routing_decision=PROCEED_CONFIRMED.

Complete SQL

Extended loan flow DDL/DML

SQL

Expected Conversation

Expected next conversation

Turn	User / System	Expected behavior
1	User: Hi	Intent GREETING, state IDLE, normal greeting response.
2	User: I need a loan for my customer	Intent LOAN_APPLICATION, POST_AGENT_INTENT moves to ELIGIBILITY_GATE, ask for missing fields.
3	User: customer id 1234, 35000, 24 months	Schema extraction fills all required fields, POST_SCHEMA_EXTRACTION moves to CONFIRMATION.
4	Assistant	Please confirm: customerId 1234, requestedAmount 35000, tenureMonths 24. Proceed?
5	User: Ohh wait, I missed one zero. Change amount to 350000.	DialogueAct=EDIT, CorrectionStep patches requestedAmount only, stays in CONFIRMATION.
6	Assistant	Updated. Please confirm: customerId 1234, requestedAmount 350000, tenureMonths 24. Proceed?
7	User: Looks good, go ahead.	DialogueAct=AFFIRM, routing_decision=PROCEED_CONFIRMED, PRE_AGENT_MCP moves to PROCESS_APPLICATION.
8	System internal	Planner runs credit -> fraud -> debt -> submit in order.
9	Assistant final	POST_AGENT_MCP moves to COMPLETED and returns the final loan summary.

Natural-language correction note

For the exact phrase “I missed one zero, it is 350000”, the cleanest path is:

1. DialogueActStep keeps the LLM candidate as dialogue_act_llm_candidate=EDIT
2. POST_DIALOGUE_ACT can use SET_DIALOGUE_ACT to restore EDIT if the guarded final result stayed NEW_REQUEST
3. CorrectionStep patches the field in place

Explicit forms like “change amount to 350000” are still the most reliable with the current deterministic patch path.

Why this flow is the recommended pattern

This example exists to solve two common problems cleanly:

• “I need rules after schema extraction, but before MCP starts.”
• “I asked for confirmation, the user said yes, and I do not want to run schema extraction again.”

The correct answer is not “stuff more prompt context into every turn.” The correct answer is to treat the turn type as a routing decision.

Post-schema, pre-MCP control points

Use both phases, but for different reasons:

Why both rule phases exist

Phase	When it runs	Use it for
POST_SCHEMA_EXTRACTION	Immediately after schema merge and schemaComplete recompute	Move to CONFIRMATION, set confirmation flags, seed lightweight runtime variables.
PRE_AGENT_MCP	At the start of MCP execution, just before planner/tool logic	Final gate for starting MCP, changing state, or skipping MCP entirely.

In this loan flow:

1. POST_SCHEMA_EXTRACTION sees schemaComplete=true
2. it sets state=CONFIRMATION
3. the active ce_prompt_template for CONFIRMATION should use interaction_mode=CONFIRM
4. optional interaction_contract can allow affirm, edit, and reset
5. optional POST_DIALOGUE_ACT rule with SET_DIALOGUE_ACT restores guarded LLM EDIT before interaction policy runs
6. user replies
7. CorrectionStep interprets the reply from prompt-template interaction metadata
8. PRE_AGENT_MCP decides whether MCP should start

That is the clean way to run rules after schema extraction but before MCP.

How confirmation turns should work

When the engine asks:

Please confirm: customerId 1234, requestedAmount 350000, tenureMonths 24. Proceed?

the next user turn should not be treated like a fresh extraction request.

Use this shape instead:

• DialogueActStep normalizes yes, go ahead, please do it, looks good into AFFIRM
• CorrectionStep checks the active prompt template (interaction_mode=CONFIRM) plus dialogue act
• if the active template allows affirm and dialogue act is AFFIRM, it sets a routing flag such as routing_decision=PROCEED_CONFIRMED
• downstream steps skip expensive or unnecessary work

This is why DialogueActStep is crucial: rules should match on the normalized signal, not raw free-form text.

How to apply rules on “yes”, “go ahead”, and similar replies

Do not write ce_rule against raw strings like:

• yes
• go ahead
• confirm

That is fragile and ambiguous.

Use a scoped runtime pattern:

Confirmation interaction pattern

Variable	Who sets it	Why it exists
interaction_mode	ce_prompt_template	Marks that this turn is a confirmation checkpoint.
interaction_contract	ce_prompt_template	Declares allowed capabilities such as affirm/edit/reset.
routing_decision	CorrectionStep	Normalizes the next branch, for example PROCEED_CONFIRMED.
skip_schema_extraction	CorrectionStep or later rule	Prevents another schema extraction call for confirm-accept turns.
correction_applied	CorrectionStep	Lets confirmation response explain that a value was updated.

Then your rules can check:

• current state
• active prompt-template interaction_mode
• active prompt-template interaction_contract
• dialogue_act
• inputParams.routing_decision

That is much safer than parsing raw “yes” in SQL.

How retry should work after MCP failure

If an MCP call fails in PROCESS_APPLICATION, the flow should stay in PROCESS_APPLICATION, not jump to COMPLETED.

Use this shape:

• POST_AGENT_MCP completion rule matches only when context.mcp.lifecycle.finished == true and context.mcp.lifecycle.error == false
• the PROCESS_APPLICATION prompt template uses interaction_mode=PROCESSING
• the PROCESS_APPLICATION interaction_contract includes retry
• CorrectionStep detects retry phrases like retry, try again, and again
• it sets routing_decision=RETRY_IN_PLACE, skip_intent_resolution=true, and skip_schema_extraction=true
• McpToolStep then runs again in the same state and re-calls the API

That gives you deterministic retry behavior without depending on state-name parsing or arbitrary runtime flags.

How to avoid another schema extraction call

This is the key optimization.

When the user has already supplied:

• customerId
• requestedAmount
• tenureMonths

and the engine is already in CONFIRMATION, a reply like:

Looks good, go ahead.

should not trigger a full schema extraction again.

Recommended behavior:

1. DialogueActStep returns AFFIRM
2. CorrectionStep sees an active confirmation prompt (interaction_mode=CONFIRM)
3. it sets routing_decision=PROCEED_CONFIRMED
4. it also sets skip_schema_extraction=true
5. SchemaExtractionStep is skipped
6. PRE_AGENT_MCP sees routing_decision=PROCEED_CONFIRMED and moves to PROCESS_APPLICATION

That avoids:

• one more LLM call
• redundant re-parsing of already-collected data
• accidental mutation of existing schema values

How partial edits should work

When the user says:

Ohh wait, I missed one zero. Change amount to 350000.

the engine should not perform a full schema extraction from scratch.

Recommended CorrectionStep behavior:

1. detect dialogue_act=EDIT
2. inspect existing schema in context
3. patch only the changed field (requestedAmount)
4. keep untouched fields (customerId, tenureMonths)
5. recompute schema completeness
6. stay in CONFIRMATION
7. set:
   • correction_applied=true
   • correction_target_field=requestedAmount
   • skip_schema_extraction=true

Then the assistant re-renders the confirmation view with only the changed value updated.

That is exactly why this example uses:

• CONFIRMATION as a dedicated state
• CorrectionStep before rework
• SET_INPUT_PARAM for lightweight runtime flags
• SET_DIALOGUE_ACT for safe post-classification dialogue-act overrides
• PRE_AGENT_MCP as the final start gate

Recommended step-level strategy

For confirmation-first business flows, the best pipeline behavior is:

Recommended routing behavior

Situation	What should happen	What should be skipped
Schema just became complete	POST_SCHEMA_EXTRACTION moves to CONFIRMATION	No MCP yet
User AFFIRM in CONFIRMATION	CorrectionStep sets routing_decision and PRE_AGENT_MCP starts MCP	Skip schema extraction; usually skip intent re-resolution
User EDIT in CONFIRMATION	CorrectionStep patches the field and re-confirms	Skip full schema extraction when patch is deterministic
User reply is ambiguous	Fall back to clarification or a small patch path	Do not blindly rerun the full flow

The design principle

Keep control in structured runtime state (inputParams, context, dialogue_act, routing_decision) and keep prompts focused on wording. Use rules and steps for routing, not prompt text for control flow.