Preparing to develop an AI agent starts with the work the organization wants to improve. Developers need to understand what an employee does today, where the information comes from and how the result is checked. Choosing a model or a technology stack can follow once the task and its constraints are clear.
The structure below is a practical starting brief for an internal assistant, document processing or a workflow connected to business systems. An initial discussion does not require a large technical specification. Concrete examples and clear boundaries are more useful at this stage.
Choose one process for the first release
Begin with a recurring task that can be separated from the rest of the work. One example is finding an answer in internal procedures and preparing a draft for a support employee. This is easier to assess than a broad request to automate the company’s support function.
Describe where the process begins and ends. Is it triggered by a person’s question, a new document or an event in another system? Is the result an explanation with a source, structured fields or a prepared task? Who receives it, and what do they do next? These answers establish the first release’s scope.
Show how the task is handled today
Ask an employee to work through several real examples and explain their decisions. Which documents do they open? How do they identify a current version? What happens when information is missing? Some process rules may exist mainly in the team’s experience rather than in formal instructions.
Record difficult situations as well: two similar records, contradictory documents or an incomplete request. These cases reveal where the application should ask questions. Without them, a convincing demonstration can conceal the gap between an ideal example and everyday work.
Where possible, distinguish a necessary decision from a workaround in the current tools. The new application should preserve the actual requirement, but it may not need to reproduce every manual step used to reach it today.
Collect examples of inputs and outcomes
A useful initial collection shows the task’s variety. Each case should include the input, the context available to the employee and an explanation of the desired result. When several answers are acceptable, define common criteria instead of requiring identical wording.
- A typical request containing all necessary information, together with an acceptable response.
- A request with missing information that should lead to clarification.
- A situation in which the available sources cannot support an answer.
- Incorrect input or several plausible matching records.
- A task outside the agreed scope that should be handed to a person.
Use examples without unnecessary personal or internal information during early discussions. If values are substituted, preserve the structure and difficulty of the case so developers can still understand the processing requirements.
Identify the sources and their owners
List the documents and services needed to produce the result. For each, note its location, how it changes and who can arrange the necessary access. Check whether interface documentation and a test environment are available for connected systems.
Also decide which source takes precedence when information conflicts. If a procedure and a business record disagree, the application needs an agreed rule or a handoff. The article on company knowledge bases explains how to prepare source material for retrieval.
Agree the boundaries of autonomy
Separate reading information, preparing an action and carrying it out. In our example, the assistant might find a procedure and prepare a response while an employee reviews it before use. Creating a record in another service would be a separate capability requiring authorization and confirmation of the outcome.
Specify when a task should return to a person. Examples include missing evidence, conflicting information and an operation outside the requesting user’s permissions. Documenting these conditions helps align expectations about how independently the application will work.
Define acceptance before the demonstration
Agree evaluation criteria before reviewing a completed implementation. For procedure search, these may include the correct source, preservation of essential steps and the absence of invented rules. For an integration, also check whether the resulting record contains the agreed data and whether service failures are handled correctly.
Evaluate the employee’s complete task, including time spent reviewing and correcting the output. Decide who will assess the pilot, how issues will be recorded and what evidence would justify broader use. The criteria should reflect the working process rather than the appeal of a single successful demonstration.
It helps to assign an owner for unresolved cases. Some will require software changes; others will reveal missing information or an internal rule that the organization itself needs to clarify.
A compact initial brief
- The process, its users and the problem in the current workflow.
- Input information and the expected outcome of the first release.
- Typical and difficult examples with explanations of correct behavior.
- Knowledge sources, connected systems and people responsible for access.
- Permitted operations, approval requirements and handoff conditions.
- Acceptance criteria and the people responsible for reviewing results.
Plan beyond the pilot
Establish who will update documents, track integration changes and evaluate new versions. Handover should explain how the application works, which permissions it needs and how to report a problem. Ongoing ownership affects whether the system remains usable in everyday work.
This preparation makes a development discussion more concrete. The team can clarify uncertainties, propose an initial scope and explain what needs to be verified before release. The article on testing AI solutions provides examples of those checks.
