# Ask QIEN: Agentic Workflow Discussion
Short answer: Ask QIEN is already partly agentic, but the safer and more useful framing is a bounded, human-in-the-loop AI workflow with agent-like subroutines.
## Recommended Framing
**Agentic inside the box. Deterministic around the box.**
The AI can reason, retrieve, summarize, draft, translate, and propose. The product still controls state, permissions, tenant boundaries, audit logging, and human approval before consequential output reaches a requester.
A shared system knowledge base can make new tenant onboarding useful on day one, but only if it is treated as reviewed, generic, non-proprietary guidance rather than as cross-tenant memory.
## Current System: Bounded Agentic Workflow
The current implementation is more than a single prompt-response system. It performs a multi-step workflow toward a business goal: resolve a quality/compliance question with expert oversight.
- Line manager submits an issue.
- System checks completeness.
- System asks clarification questions when needed.
- System summarizes and retrieves KB context.
- System drafts a response.
- Expert reviews, edits, approves, or overrides.
- System records artifacts, translations, state, and audit history.
## Possible Evolution: Ticket Resolution Agent
The next step is not necessarily more autonomy. It is making the AI work product more coherent, inspectable, and action-oriented for the expert.
- Own a ticket until it is ready for expert review.
- Choose whether to clarify, retrieve, summarize, draft, or flag low confidence.
- Produce a structured reasoning package.
- Recommend next actions without taking irreversible action.
- Maintain English/Spanish parity and translation status.
## Information Flow
| Today: Designed Workflow With AI Steps | Next: Ticket Resolution Agent Inside Guardrails |
| --- | --- |
| **1. Submit issue**
Structured intake and free-text context. | **1. Understand ticket goal**
Agent builds a case model, not just a single prompt output. |
| **2. Completeness check**
AI decides if more information is needed. | **2. Plan safe next step**
Clarify, retrieve, summarize, draft, or flag uncertainty. |
| **3. Clarification or queue**
State machine controls the path. | **3. Gather evidence**
System KB, tenant KB, prior tickets, tenant config, and ticket history. |
| **4. Summary and draft**
AI creates artifacts for expert review. | **4. Produce review package**
Draft, sources, confidence, assumptions, gaps, translation status. |
| **5. Expert response**
Human expert sends the final answer. | **5. Human approval gate**
Expert reviews before anything goes to requester. |
| **6. Audit and translations**
System records what happened and what language variants exist. | **6. Propose system improvements**
KB update proposals, routing hints, repeated issue detection. |
| **Strength:** predictable, auditable, controlled. | **Strength:** richer expert support without black-box autonomy. |
## Knowledge Strategy: Shared System KB
Some knowledge will be broadly useful across customers: domain concepts, general compliance process, non-proprietary best practices, and reusable explanation patterns. This should live in a system-level KB that is available during onboarding and retrieval, separately from tenant-specific knowledge.
- Seed new tenants with useful general guidance.
- Keep tenant KBs private and tenant-scoped by default.
- Promote only reviewed, generic, non-proprietary entries into the system KB.
- Label source, scope, approval status, and intended applicability.
- Allow experts to propose candidates when repeated issues reveal reusable guidance.
## Governance: Promotion Guardrails
The fine line is not just technical. It should be reflected in workflow, review policy, customer-facing terms, and internal operating procedures.
- No automatic promotion from tenant tickets, chats, documents, or approved answers.
- Require human review before system KB publication.
- Strip customer names, product identifiers, site details, and proprietary process detail.
- Preserve audit history for who proposed, reviewed, approved, edited, or retired an entry.
- Document what may be generalized in terms of service, terms and conditions, or a knowledge-use policy.
## What To Keep: Deterministic Shell
- Ticket state machine
- Role-based access control
- Tenant isolation
- Audit trail
- Human approval gates
- Stored language variants
- Tenant-private KB boundaries
## What To Add: Agent Work Product
- **Explicit confidence:** show whether the agent thinks the draft is ready for expert review, needs more information, conflicts with available evidence, or should be treated as low confidence. This should be a workflow signal, not a claim of correctness.
- **Known assumptions:** list the facts the agent is relying on but cannot independently verify, such as product context, site conditions, requester intent, applicable procedure, or regulatory scope. Experts should be able to confirm, edit, or reject these assumptions.
- **Evidence and source map:** connect each major recommendation or draft claim back to the source that supports it, such as system KB, tenant KB, prior ticket history, uploaded documents, tenant configuration, or requester-provided details. This makes the draft inspectable instead of merely plausible.
- **Regulatory traceability idea:** when a ticket appears to involve regulated manufacturing, the review package could show potentially relevant source families and canonical links, such as [FDA 21 CFR Part 820 / QMSR](https://www.fda.gov/medical-devices/postmarket-requirements-devices/quality-management-system-regulation-qmsr), [21 CFR Part 803](https://www.ecfr.gov/current/title-21/chapter-I/subchapter-H/part-803), [21 CFR Part 806](https://www.ecfr.gov/current/title-21/chapter-I/subchapter-H/part-806), [21 CFR Part 11](https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11), [21 CFR Part 210](https://www.fda.gov/drugs/pharmaceutical-quality-resources/current-good-manufacturing-practice-cgmp-regulations), [EU MDR](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex%3A32017R0745), [ISO 13485:2016](https://www.iso.org/standard/59752.html), or [ISO 14971:2019](https://www.iso.org/standard/72704.html). This should be treated as an expert-facing aid, not legal advice or an automated compliance determination.
- **Regulatory rationale:** for each cited source, explain why the source might matter to this ticket, what facts would need to be confirmed, and which record, complaint, CAPA, correction/removal, electronic-record, quality-system, risk-management, or GMP question it may touch. Ramon should validate the right source set and the appropriate level of specificity.
- Unanswered questions
- KB gap proposal
- System KB promotion proposal
- Translation parity status
## What To Avoid: Unsafe Autonomy
- Sending requester responses without review
- Editing approved KB directly
- Closing tickets automatically
- Retrieving private tenant knowledge across tenants
- Learning from customer data without explicit governance
- Unlogged tool use
- Runtime translation drift
## Decision Points for James and Ramon
| Area | Question |
| --- | --- |
| Product framing | Do we want to describe Ask QIEN as an AI workflow, an expert copilot, or a bounded ticket resolution agent? |
| Autonomy level | Should the AI only prepare expert work product, or should it also recommend routing, escalation, and closure? |
| Trust model | Which actions always require human approval? Which actions can be automated safely? |
| Expert UX | What would make an expert faster: a better draft, or a fuller review package with sources, gaps, and assumptions? |
| Compliance posture | How much audit detail should be visible to customers versus retained internally? |
| System KB policy | What categories of knowledge can be generalized across tenants, and where should that be disclosed contractually? |
| Promotion workflow | Who can propose, review, approve, edit, retire, or block entries from becoming shared system knowledge? |
## Practical Recommendation
Evolve toward a ticket resolution agent, but keep the existing human-in-the-loop state machine as a product strength. The agent should prepare, explain, and recommend. The system should continue to control permissions, auditability, and release of final answers.
Implementation should probably be staged, especially because production currently has very little real usage data and Customer Zero is still barely poking the tires. The immediate goal is not to build a large autonomous agent platform. It is to make the existing AI work product more reviewable, learn what experts actually find useful, and avoid overfitting the product to imagined workflows.
A lightweight first version would be mostly product and prompt structure:
- Add an expert-facing review package that groups the draft, confidence, assumptions, source references, unanswered questions, and translation status.
- Store that package as a first-class ticket artifact so it can be inspected later instead of disappearing as transient prompt output.
- Add basic feedback controls for experts, such as useful/not useful, assumption corrected, source missing, or draft unsafe.
- Keep all outward-facing requester communication behind the existing expert approval gate.
A medium version would add more durable knowledge and governance:
- Track which KB entries, tenant settings, prior tickets, and source materials were used to produce each draft.
- Add a proposal workflow for KB gaps and system KB promotion candidates.
- Add review states for shared/system KB content, including proposed, approved, rejected, retired, and source/version metadata.
- Add tenant-level controls for whether system KB, regulatory source packs, or prior-ticket retrieval are enabled.
A larger version would be the regulatory and evaluation layer:
- Build a source registry for FDA, EU MDR, and licensed ISO materials, with versioning and jurisdiction/sector tags.
- Add retrieval over approved regulatory source packs and show source-specific rationale in the expert review package.
- Create evaluation tickets and regression tests for unsafe regulatory claims, missing citations, bad confidence signals, and tenant-boundary failures.
- Add reporting so the team can see whether experts accept, edit, ignore, or override the agent work product.
Given the current lack of production data, the safest near-term move is a thin vertical slice: one clearer review package, one or two feedback signals, and logging of the evidence used. That would create learning data without pretending the system already knows the full workflow.
---
Prepared for internal discussion. This is a product and architecture framing document, not a commitment to implementation scope.