Use a regular workflow when inputs, rules and steps can be defined clearly. An AI agent can be useful when a task involves unstructured information, language-based requests or choosing between approved tools. One process may need both: AI interprets the request, while ordinary software validates and executes it.
For a first release, choose one bounded task such as finding an order or drafting a response from approved documents. Define the data it can read, the actions it can take and the point at which a person must review the result. Start with a representative set of real tasks and compare completion quality, review effort and cost with the existing process.
Begin with the questions employees or customers actually ask. Collect the documents needed to answer them, remove duplicates, identify the owner of each source and agree how updates reach the system. Preserve document dates and access permissions when indexing content.
Useful answers should point back to the relevant source and acknowledge missing evidence. Evaluate common questions alongside ambiguous requests, outdated material and questions the system should not answer. Test with accounts that have different permissions. A polished chat screen is only one part of the delivery; source management and evaluation need an owner too.
Agree a test set before development: normal requests, missing fields, conflicting information, unavailable services and duplicate submissions. Record the expected outcome for each task, including when the system should ask for clarification or pass work to a person.
During acceptance, inspect tool calls and resulting business records. Confirm that permission checks, review steps, retry limits and duplicate protection behave as agreed. Measure task completion, error patterns, response time and cost under the planned workload. Keep the accepted test set so later changes to models, prompts or integrations can be compared with the baseline.
How we refreshed our website while preserving old article links
This is a record of our own website, not a client case study. In September 2026 we consolidated repetitive guides around distinct business questions and kept 134 legacy article and pagination redirects. Old links lead to the matching page or section rather than all pointing to the homepage. Unknown pages continue to return a real 404.
For the 14 September release, we checked 168 page and asset responses against the release files, along with the legacy redirects and English navigation. We backed up the previous version and retained older static assets for already-open pages. These are engineering checks, not counts of indexed pages or evidence of higher rankings.
We also checked contact fields and the API response to a request missing required information. No real enquiry was sent as part of that check, so it does not establish end-to-end notification delivery. Search visibility, AI citations and qualified enquiries require their own measurements over time. Keep these outcome measures separate from a successful build or release.
Describe who starts the process, what they need to do and how the team knows it is complete. Map the screens, data, integrations and operational responsibilities needed for that journey. Include the exceptions that would prevent real use, such as a rejected payment or a cancelled booking.
Separate essential launch work from assumptions that can be tested later. Confirm the release scope with a prototype and written acceptance examples. Agree who owns domain names, cloud accounts, source code, deployment instructions and maintenance. For remote collaboration, schedule reviews around usable versions and specific decisions rather than relying on progress percentages.