Build an acquisition workflow with AI—and a human in the loop

Automate a defined job

Begin with a workflow you can describe without mentioning AI: receive an inquiry, validate required fields, create an opportunity record, assign a next action, and remind the responsible person. If the underlying process has no owner or completion criterion, adding a language model usually makes uncertainty faster rather than smaller.

Write the input, allowed output, responsible reviewer, and failure path for each automated step. A model that summarizes seller notes has a different risk profile from one that sends an offer. Start with reversible, internal assistance and measure quality before expanding authority.

Keep evidence separate from generated interpretation

Preserve original notes and documents alongside summaries. A model can omit a qualification, merge two addresses, or interpret a tentative statement as a commitment. Store the source record and mark generated text as a summary. Give the reviewer a direct route back to the evidence.

For extracted fields, record confidence and unresolved ambiguity. If a document mentions both a parcel address and a mailing address, the workflow should not silently choose one as the property location. Route uncertain fields for review before they reach valuation, contact, or document systems.

Set boundaries before connecting actions

Create a permission matrix. Reading a file, writing an internal note, changing a stage, sending a message, and executing a transaction are separate capabilities. The fact that a system can draft language does not mean it should send it without review. Default sensitive external actions to a human approval step.

Protect credentials and personal information. Use server-side secrets, restricted access, retention rules, and only the data necessary for the task. Do not send complete seller documents to a tool merely because a small field is needed. Assess the service’s data handling before integrating it.

Build a simple, auditable workflow

A practical first version validates an inbound inquiry, checks for duplicates, creates a record, generates an internal summary, and assigns a reviewer. The reviewer verifies property identity, contact preferences, and the next action. Only then does the system schedule a permitted follow-up or prepare a draft for review.

Every action should produce a timestamp, actor, input reference, output, and outcome. Log failures as explicitly as successes. An error queue with an owner is more useful than a silent retry loop that creates duplicate messages or records. Use idempotency keys for operations that may be retried.

Measure accuracy and usefulness

Create a small evaluation set representing typical and difficult inputs: incomplete addresses, contradictory statements, duplicate submissions, handwritten notes, and requests to stop contact. Measure the errors that matter to your workflow rather than a vague overall quality score.

Track how often the system invents a missing fact, misidentifies a property, loses a qualification, or routes a record incorrectly. Review examples with a human before changing prompts or models. Keep the evaluation version so an apparent improvement in one area does not hide a regression elsewhere.

Protect fair access and human judgment

Automated ranking and messaging can create harmful or unlawful outcomes when they use inappropriate features or proxies. Review fair-housing and other applicable requirements with a qualified professional before implementing systems affecting housing opportunities. Do not assume a model’s output is neutral simply because it is numerical.

Use AI for bounded assistance: organizing information, identifying missing fields, drafting internal checklists, or suggesting questions. Keep consequential decisions explainable and reviewable. The NIST AI Risk Management Framework is a useful starting point for governing, mapping, measuring, and managing these risks.

Draw the boundary around one assisted decision

Start with a single task, such as converting an incoming inquiry into a draft internal record. Write what the assistant may infer, what it must quote or extract, and what it must leave blank. For example, it may normalize the formatting of a supplied phone number, but it should not invent a missing digit. It may summarize a stated timing preference, but it should not label the person as desperate or predict willingness to accept a discount.

Give every field an allowed evidence source. Property identity may require a verified record; preferred contact time may come from the person's own message. Keep those categories visible to the reviewer. A draft that includes a value in every field may look more complete while being less trustworthy than one with explicit gaps. Define success as a usable, accurately qualified record, not the elimination of empty cells. This makes the human review smaller and more focused because each output has a known evidentiary job.

Build review screens that support actual checking

A human approval step only helps when the reviewer can see what needs approval. Present the original excerpt beside each consequential extracted field and highlight differences from the prior record. If a new message changes the preferred contact channel, show that change directly. Do not require the reviewer to open six documents and remember their contents before seeing the proposed update. Friction can turn a meaningful review into habitual acceptance.

For a hypothetical incoming note, “The house is at 18 Cedar; mail goes to 81 Cedar,” the screen should display both source phrases and flag the two addresses rather than filling one address field with an unqualified choice. The reviewer can verify the property identity and record the resolution. Keep a reason for manual corrections so recurring ambiguities can inform workflow changes. Reviewer speed is useful, but a very fast approval rate can also signal inadequate inspection. Examine actual corrected and approved examples before declaring the interface effective.

Make escalation a defined outcome

Create a short list of situations that must stop dependent automation. Examples include contradictory property identities, an uncertain request to stop contact, missing permission for the proposed action, or an instruction inside an uploaded document that attempts to change the workflow. Treat source documents as information to be analyzed within the authorized task. A sentence in a document telling the assistant to reveal records or contact another person is not itself operational authorization.

Specify what happens when the boundary is reached: mark the record, preserve the relevant evidence, assign a reviewer, and prevent the dependent action until resolved. Avoid a generic “something went wrong” status. A reviewer needs to know whether the problem is incomplete data, conflicting evidence, a service failure, or an attempted instruction outside the task. This is also a practical way to preserve useful assistance. The system can finish safe internal work while holding the specific action that depends on unresolved information.

Test against consequences rather than polished wording

Build a small evaluation batch with known expected results. Include easy inputs, unclear inputs, and inputs that resemble each other but require different outcomes. One message might request a price discussion; another might only ask how you obtained the phone number. Both mention contact, but they should not automatically produce the same next action. Have a responsible human define the expected record and acceptable handling before running the system.

Suppose a hypothetical trial includes forty records. Thirty-seven drafts look readable, but two attach notes to the wrong property and one fails to preserve a contact restriction. Reporting a 92.5% readable-draft rate would miss the most important defects. Report identity errors, lost restrictions, unsupported facts, and correction time separately. The percentage is 37 divided by 40; it is not evidence the workflow is ready for autonomous actions. Review each consequential failure, change the relevant control, and rerun the affected cases together with previously passing cases.

Control changes as carefully as the first release

Save the task instructions, field definitions, integration settings, and evaluation version associated with a release. When changing a model or prompt, first compare it against the same known cases. Record what improved, what regressed, and who accepted the remaining limitations. A better summary style does not compensate for worse identity handling. Distinguish a cosmetic preference from a change that affects what data moves or what action becomes possible.

Deploy a bounded internal version before widening access. For example, use the assistant to draft records for one reviewer during a defined trial while the established process remains available. Set a stop trigger for any material identity mix-up or unauthorized action, and decide who can disable the integration. The trigger should produce an investigation and corrective work, not a promise that no errors will ever occur. A controlled rollout gives you evidence about the actual workflow instead of relying only on demonstration inputs selected because they look easy.

Keep operational ownership visible

Assign separate responsibility for data quality, workflow operation, and consequential decisions, even if one person initially fills several roles. The data owner resolves conflicting records. The operator investigates failed jobs and provider errors. The decision maker approves an action using the verified evidence. Write the responsibilities down so a failed integration does not become everyone's concern and nobody's task.

Consider an inquiry received Friday evening. If extraction fails and the normal reviewer is away, the workflow should have a named queue owner and a reasonable internal response target. A reminder sent to an unattended inbox does not create accountability. During the next operating review, inspect unresolved items and ask whether deadlines are realistic for available staff. Human oversight has a capacity limit. If incoming volume exceeds review capacity, restrict the automated process or increase qualified review resources rather than allowing unreviewed drafts to become accepted facts through age alone.

Reconcile the assistant's output with the system of record

A useful workflow ends with an explicit disposition: approved, corrected, rejected, or awaiting specified evidence. Preserve the original source and the approved version while applying the appropriate retention rules. Avoid leaving two competing draft records in different tools with no clear authoritative copy. If an approved correction is made later, record who changed it and why so downstream users can understand the current state.

At a periodic review, select a small sample of completed records and follow each from inquiry to final internal action. Ask whether the source remains accessible, important qualifications survived, and the human decision is understandable. Compare time saved with time spent correcting and investigating. If the tool creates attractive summaries but shifts more verification work onto staff, narrow the task. The practical test is whether the entire process becomes more reliable and usable, including its failures, rather than whether an individual AI response sounds competent.

Have a manual fallback

Document how staff continue if the integration is unavailable, the model changes, or a provider stops responding. Export records in a standard format and test that the original evidence remains accessible. A workflow that cannot operate manually has made availability another hidden dependency.

Before expanding automation, ask whether it actually reduces errors and response time without increasing complaints, data exposure, or rework. The best acquisition system is one you can inspect, correct, and trust within clear limits. A human in the loop needs enough context and authority to stop an unsafe or inaccurate action.

• Define the task and its failure path.
• Retain source evidence.
• Separate draft generation from sending.
• Validate fields and detect duplicates.
• Log actors and outcomes.
• Evaluate difficult inputs.
• Maintain an export and manual fallback.