Abstract
A workflow that drafts requirements from a conversation needs several steps: collect the source material, prepare the inputs, produce the draft and present it for review. If it also calls tools, it needs to record what those tools did and check their outcomes before continuing.
This paper describes our proposed architecture for those steps. It covers source references, tool permissions, approval, revisions and recovery after an interruption. Turnwise provides live capabilities; some of the architecture described here remains proposed work.
1. Define the task and its finishing condition
A request such as “prepare the requirements” does not define a useful stopping point by itself. The system needs the audience, source material, output form and conditions under which the result is ready for review. It also needs to know which actions belong to the workflow and which belong to a person.
We frame the task around a deliverable and its acceptance conditions. For a conversation-derived specification, that can mean an editable draft, source references, unresolved questions and a record of review. It does not mean that the specification has been accepted merely because a model generated it.
A template is valuable when it makes these conditions repeatable. Its structure can identify required inputs, the intended output and the next reviewer.
2. Record the inputs and source references
The workflow needs to distinguish a source statement from an inferred interpretation and both from a later human decision. A transcript passage, document clause or visual annotation should remain connected to its original material. A revision should record what changed instead of silently replacing the earlier understanding.
Our proposed task context has five elements: the user's objective; permitted source references; extracted observations; open questions; and the current deliverable revision. Tool results and review events can add to the record, but they should not become instructions merely because they appear in retrieved content.
Conflicting sources are a useful test. If a proposal says Thursday and a later recording says Friday, the system should preserve the discrepancy and request the relevant decision. Context compression that loses that difference can produce a smooth answer at the cost of the task's meaning.
3. Separate model output from tool actions
The architecture direction separates four responsibilities. A context layer prepares permitted material. A reasoning layer proposes interpretations and next steps. A tool layer executes bounded operations under current authority. A task record retains results, revisions and review state.
Separating them lets the workflow test whether a proposed action is permitted before trying it. A model's suggestion to read, write or send is not itself authorization. The task record should distinguish a proposed action, an attempted action, a confirmed result and an outcome that remains unknown.
Research such as ReAct explores the combination of reasoning and acting in language-model systems. It is relevant background for an agentic design. A product still has to supply the surrounding authority, state and review boundaries needed by its users; a research interaction pattern does not establish those boundaries on its own.
A useful action record says what the workflow tried, what the tool confirmed and what still needs a decision.
4. Set review and approval points
Human review should be attached to a consequential decision rather than added as an empty confirmation at the end. The reviewer needs the proposed deliverable, the material supporting its important claims and the questions the system could not settle.
For a requirements workflow, this means keeping the conversation passages near the proposed wording. For a document workflow, it means preserving the relevant source rather than showing only extracted fields. For a multi-step task, it means explaining why the next action is available, waiting or outside the current authority.
Show the reviewer which actions were proposed, which ran and which outcomes were confirmed.
5. Check outcomes after an interruption
A failed connection is not always proof that an operation failed. The workflow may have issued a request without receiving its result. Retrying automatically can duplicate an action; treating it as complete can omit work that still needs to happen.
The proposed recovery model retains the request identity, the intended operation and the last confirmed state. Before retrying a consequential operation, the workflow should ask the relevant system what happened, where that is possible. If the state cannot be established, the uncertainty should remain visible and the next step should be bounded accordingly.
Revision recovery has a related requirement. A task should resume against the current source and current permissions, not solely against what was true when it started. Losing access, changing a source or modifying an approval can change which continuation is valid. The correct response may be to keep the deliverable while pausing a dependent action.
6. Test the model and workflow separately
A fine-tuned model may improve a recurring recognition or interpretation task. The surrounding agentic workflow still needs to decide which material it can use, how to keep evidence connected and what actions follow. Better model quality does not automatically improve authority checks or recovery.
Conversely, a well-structured workflow can improve a result without changing model weights. It can obtain the missing source, ask a better clarification question, enforce an output format or keep a human decision attached to the correct revision. This is why our research compares model adaptation with changes to context preparation and workflow structure.
Multimodal inputs make the separation particularly useful. Speech can supply a change, a document can supply the agreed scope and a visual note can supply location context. The system should retain their relationships even if different models process them.
7. Research automation, current features and proposed tests
The completed initial speech programme used AI-assisted workflows for data preparation, experiment execution, evaluation scripts, error categorization and documentation. Humans governed research design, dataset acceptance, evaluation criteria and interpretation of findings.
The exploratory video programme uses agent-assisted preparation, references, editing, assembly and quality checks. Human creative acceptance remains distinct from technical file checks. Matched manual and agent-assisted production comparisons are proposed further work.
Turnwise is the current public entry point into Indriya's agentic work. Its product site describes conversation review, protected source playback, text and voice questions, collaborative requirements review, revision history and specification exports. Its eight starter templates each describe a reusable pattern, with examples of its application. Discovery and definition clarifies a need and produces a reviewed brief. Solution design develops an approach from that brief. Requirements to Proposal illustrates how these templates can contribute to the same task.
A proposed architecture test would exercise a clearly defined task under normal conditions, missing inputs, conflicting sources, an interrupted tool and a revoked permission. It would measure useful completion and correction effort while recording whether the workflow crossed an action boundary or lost the source of a claim.
Customer-driven investigations in teaching, learning and buyer discovery supply additional settings in which to examine the same relationships.
Model access in the research architecture
Our ongoing model work includes NVIDIA and Google open weights and Apple AFM 3, with cloud Mac experiments alongside the AWS environment. The workflow should record which model handled each modality, the actual runtime and whether processing stayed on the Mac or used a cloud endpoint.
A model interface should declare image, audio and video input support, output types and applicable limits. Open-weight customization, prompt changes and Apple framework integration are different interventions. Tool authority stays outside the model.
References and source notes
References checked on 14 October 2026.