Question
How do you design the handoffs between people and agents?
Work
Service design, agent interaction design, workflow development and presentation prototyping.
I knew what I wanted PadSquad’s proposal workflow to do. A person would supply a brief, agree on the direction and receive an editable presentation to review.
The first design used seven separate agents supporting different stages of the process. I initially expected to place review steps between those stages.
Building and testing changed that thinking. As the work compressed, some of those stops became interruptions with little useful purpose. The exploration became as much about how people interact with agents as the work the agents perform.
Simplify the experience around the work
The separate agents reflected different activities involved in preparing a proposal. But the person using them was trying to accomplish one thing.
We brought those activities behind a single entry point: PadSquad Proposal Builder. The user supplies a brief, reviews the proposed scope and approves the direction. The workflow then handles the permitted drafting, slide layout, preparation checks and PowerPoint generation.
Testing exposed details that still made the experience confusing. A follow-up brief selected an older intake workflow, so we clarified the routing instructions and tested a fresh launch.
We also renamed the entry point and made the six older standalone agents private. The shared catalog now gives people one clear place to begin.
Put review where a decision matters
Removing a stop requires understanding what that stop was meant to accomplish.
Which decisions had already been made? Which missing inputs should hold the work? What could remain pending in a useful draft? We refined those conditions so the workflow could continue within the direction the user had approved.
The remaining interactions needed to give people something meaningful to assess. At scope review, that means understanding what the system proposes to create. At final review, it means inspecting the actual deck.
We learned that the PowerPoint became available after the run completed. That determined where final file review belonged.
Scope approval permits drafting. The generated file still needs review, and client release remains a separate decision.
Translate judgment into instructions
I could describe the outcome and explain what felt wrong with a result. Codex helped me express those expectations at a level of detail I would not naturally write myself.
That included inspecting Veylan’s available capabilities and defining the steps and conditions the saved workflow could execute.
It also included translating an example proposal into presentation rules: how different slide types should use typography, images, panels and footers, and what should happen when content did not fit.
Veylan provided the execution environment, review checkpoint and native PowerPoint generation. Codex helped develop and test the instructions. I supplied the business context and judged whether the result served the goal.
Learn from the actual deliverable
The generated PowerPoint exposed overlapping content, broken headings and footer collisions.
We rendered the file, inspected every slide and revised the layout rules. Each output gave us evidence for the next improvement. My feedback became more precise as I could see where the design broke down.
The checks served different purposes. Veylan’s preparation check evaluated proposed content and layout. Codex’s inspection of the rendered slides happened outside the workflow.
The latest test deck passed source and visual review. A controlled user pilot will test how consistently the experience holds up across different briefs and decisions.