From client brief to tested AI feature: a practical agency workflow

A client brief often starts with an outcome: fewer repeated questions, quicker access to information or a simpler task for staff. AI can help explore possible implementations, but the agency still needs to define the feature that will be built and the evidence that will make it acceptable.

This article sets out a recommended workflow for scoping and delivering one AI-assisted product feature. It is not a claim that Curiosive has followed this exact process on a named client project, and it does not promise a delivery speedup.

The concrete example is a proposed support-reply drafting feature. It retrieves approved product information, prepares a draft for a staff member and leaves sending the reply to the existing authorized workflow. The example keeps discovery, implementation, testing and handoff connected.

Discovery: identify the task before choosing the AI

Start with the person doing the work. Which questions repeat? Where is the approved information? What makes a reply useful, and what mistakes cause rework?

Gather a small, representative set of requests and the responses staff consider acceptable. Include questions that cannot be answered from the available material. This becomes an evaluation input, not a collection of prompts selected only because a demo answered them well.

Map the existing workflow. An AI draft is less useful if staff must copy context across several screens or cannot see the source behind a recommendation. Decide where the feature belongs and who will review its output.

For a client conversation about AI integration, these details define a more useful brief than naming a preferred model. They identify the task and its acceptance boundary.

Scope: choose one vertical slice

Define the first feature from input to outcome. For the example, the input is a selected support request and authorized product documents. The output is a draft with source references, visible limitations and an explicit staff review step.

State what the slice does not authorize through its actual interface and access policy. Drafting does not imply sending, refunding or changing an account. The product should expose the intended actions directly rather than rely on a model to infer those boundaries.

Separate assumptions from decisions. If the documents lack version information, identify that as a discovery issue. If staff need a particular tone, include examples and a review criterion. Do not leave critical requirements buried in an informal conversation.

A useful scope artifact names the user, input, output, allowed actions, failure states and acceptance examples. The client can review that artifact before implementation expands.

Implementation: build a baseline before adding autonomy

Begin with the application path and deterministic checks. Confirm that the feature can select the correct request, retrieve permitted information and display a reviewable result. Mocked responses can help test the interface without depending on a live model for every iteration.

Put model calls behind an adapter with a defined output contract. Validate the returned structure. Preserve the source references used for the draft and show the reviewer which product version or document was consulted.

Then compare generated drafts with the accepted examples. AI-assisted coding can help create components, adapters and checks, but review should inspect their fit with the existing project architecture. Keep credentials and data access scoped to the feature.

For retrieval details, our hybrid AI search guide explains semantic queries, exact terms and filters. The agency task is to connect those mechanisms to this client’s corpus and users.

Integrations: specify what happens when a dependency fails

An integration is not complete because one request succeeds. Define behavior for unavailable documents, expired credentials, model timeouts and repeated submissions.

If no approved evidence supports an answer, the interface should identify the gap rather than manufacture a confident reply. If generation fails, preserve the selected request and allow staff to continue manually.

Decide how retries work and whether an existing result can be reused. Keep background work visible with a known status. Do not let a retry duplicate a downstream action.

Document the data sent to each dependency and what is retained. That gives reviewers a concrete basis for assessing the feature instead of a vague statement that the AI integration is private or secure.

Review: use tools to find leads, then check the behavior

Rowan, introduced in a recent Show HN submission, illustrates a useful kind of supporting tool: static inspection of code and AI-related configuration. Its README labels the scanner alpha and treats findings as leads rather than confirmed vulnerabilities. It also says a clean report does not prove security.

We have not installed Rowan or scanned a client project with it. Its documentation is a reminder to keep tool output and verified findings separate. A scanner can inform review; it cannot establish that runtime permissions and business behavior are correct.

For the proposed feature, review input handling, retrieval permissions, output rendering and the actions exposed to staff. Check sensitive findings before sharing reports, since diagnostic artifacts can contain source or secrets. Use checks appropriate to the project rather than adopting a new tool simply because it appeared in a launch.

Testing: make acceptance examples executable where useful

Test the ordinary path and the important failures. A valid request should produce a reviewable draft with its evidence. An unauthorized document should not reach the model. A timeout should leave a recoverable interface state.

Use representative content to evaluate answer support, omissions and tone. Keep expected behavior explicit when the corpus cannot answer a question. Review the cases where a fluent draft is plausible but unsupported.

Test the real interaction on the relevant screen sizes and assistive paths. Staff should be able to inspect the source, edit the draft and understand its status. Automated tests should check meaningful behavior, not merely repeat the implementation.

The Curiosive editorial delivery walkthrough describes a demonstrated website release with type, test, build, metadata and live checks. An AI reply feature needs its own functional and evaluation checks in addition to those ordinary delivery steps.

Delivery: hand over the accepted feature and its operating limits

The handoff should include the approved scope, actual changes, validation results and known limitations. Name the owner of credentials, document updates and model configuration. Explain how to disable or roll back the feature if its dependency becomes unavailable.

Keep the accepted baseline and evaluation examples available for later changes. A model upgrade or retrieval change can alter answers without changing the visible interface. Recheck the relevant acceptance cases when those dependencies change.

Release through the project’s established workflow and verify the deployed feature. A successful build does not prove that production credentials or integrations behave as expected. Where verification cannot safely exercise an action, record that limitation and the remaining acceptance step.

Discuss the workflow you want to improve

The value of an agency AI project comes from a usable, reviewed feature in the client’s existing workflow. This recommended approach turns a broad idea into a scoped slice with evidence at discovery, implementation, testing and delivery.

If you have a repetitive task worth improving, bring its examples to Curiosive. We can discuss the feature boundary and AI integration requirements. See our approach for how we frame product work.

Sources and scope

Reviewed October 3, 2026: Rowan’s official README and Show HN entry, submitted October 3. There was no substantive HN discussion when read. Scanner descriptions are source-reported; no scan was performed. The support-reply feature and workflow are illustrative recommendations, not a Curiosive client case study or a claim of demonstrated delivery outcomes.