This write-up describes the system intent and engineering approach for an active build. It does not claim shipped functionality, measured performance, regulatory approval or customer outcomes that have not been published.
Design objectiveMove from a clear user intent to a verified answer or confirmed action
A traceable path from input to outcome.
- 01Understand
Resolve the user’s intent, missing details and task state.
- 02Ground
Retrieve approved information and check current service data.
- 03Prepare
Validate a typed action plan against the allowed tool contract.
- 04Confirm
Show the user the material terms before a consequential action.
- 05Verify
Execute once, reconcile the result and return a traceable receipt.
From conversation to a dependable outcome
A conversational interface is useful when it can do more than produce fluent text. Users may ask a question, compare options, or ask for a task such as booking a ticket. These requests have different risk: an informational answer can be corrected, while an external booking can create a charge or a commitment.
Agent Relogic is being shaped as a custom generative-AI conversation tool. Its core design rule is to distinguish answering from acting, then make the evidence, required details and action boundary visible to the user.
A controlled task-execution flow
For a ticket request, the agent should not jump from an open-ended prompt to a booking API call. The system first resolves what the user means, checks live options through approved services and presents a reviewable proposal.
- Intent and slot resolution: identify the task and collect required fields such as route, date, passenger count and relevant preferences; ask a focused follow-up when a required value is missing.
- Grounded option search: call an allowlisted availability or catalogue service and keep provider results separate from model-generated explanation.
- Action preview: show the selected option, total price, important restrictions, passenger details and any cancellation or change terms before asking for confirmation.
- Confirmation gate: require an explicit user confirmation for the exact action and terms. A changed fare or unavailable option returns to review rather than silently continuing.
- Transaction and receipt: execute through a server-side adapter, use an idempotency key, reconcile timeouts against the provider, and return the confirmed provider status or a clear failure state.
Separate language, policy and transactions
The proposed service boundary has a conversation interface, a session and task-state store, a policy and intent router, a retrieval layer for approved knowledge, and a tool gateway that exposes typed operations to the model. Provider credentials stay in the server-side integration layer; they are never placed in browser code or a model prompt.
Retrieved text and user-provided content should be treated as untrusted input. Tool authorization must be enforced by the gateway and the user’s permissions, not by an instruction in a prompt. Booking, payment and account changes should use narrowly scoped operations with server-side validation and an audit record.
Design for retries, handoff and recovery
External services fail in ways that can leave the user uncertain: a timeout may happen after a provider accepted a request, or a fare may change between search and submission. The integration must distinguish a rejected action from an unknown result and reconcile the latter before inviting the user to retry.
The user-facing answer should identify its source, state what was actually completed and provide a receipt or next step. If the request exceeds the system’s authority, the source is unavailable or the provider response is ambiguous, route the conversation to a human instead of inventing a successful outcome.
Evaluation for answers and actions
The answer path and the action path need separate scorecards. A model can explain an option well but still choose the wrong tool arguments; a booking can succeed technically while the conversation fails to collect the right details.
- For answers: test source-grounding, factual correctness, refusal or escalation behavior and response usefulness on a reviewed query set.
- For tasks: test intent and field extraction, tool selection, argument validity, confirmation behavior, provider-state reconciliation and receipt accuracy.
- Exercise adversarial instructions in retrieved content, duplicate submissions, timeouts, changed availability and partial provider failures.
- Define acceptance thresholds with the product owner before pilot use; no live booking integration or success rate is claimed by this page.
Current build focus
The build should establish one bounded task end to end: clarify missing details, retrieve current options, ask for confirmation, execute through a controlled adapter and verify the result. The same policy and observability layer can then be reused for additional user requests.