# Can I give AI a business goal instead of step-by-step instructions?

Yes. Give AI a clear goal, such as reducing repeat document requests during customer onboarding. Tell it how success will be measured, what it may access and change, and who approves the plan. It can then work out the steps and ask about missing information.


> By Saad Bin Shafiq, founder of Nodes · Sep 27, 2026
> Canonical: https://www.nodes.inc/blog/ai-business-goal-to-workflow


---
**Illustrative example:** A leader says, “Fix onboarding.” A usable brief defines a case type, a reduction in repeated document requests, and the required checks that must remain. It names the CRM, support records, current requirements, permitted follow-up tools, and an exception owner. It also sets a period for measuring time until the customer can start using the service, rework, and customer effort. The example describes a possible configured workflow, not a deployed customer result.

## Turn the request into a brief

A good goal tells a system what matters without pretending every step is known in advance. Write down the business result, the current baseline, the population or case type, the owner, the deadline, and the boundaries. State what the system must never infer. “Missing document” should not be guessed from a blank field if a late feed or failed match could produce the same blank.

The first answer may be a question back to the owner. Which onboarding journey is in scope? What counts as a repeated request? Does the team have permission to send a customer message, or only to draft one? Those questions prevent a polished workflow from solving the wrong problem.

| Brief element | Onboarding example |
|---|---|
| Result | Fewer repeat document requests for a defined case type. |
| Baseline | Existing time until the customer can start using the service, rework, and customer contacts. |
| Evidence | Current requirement, document status, account owner, prior requests. |
| Authority | Read permitted records; create routine tasks if delegated; review customer-facing exceptions. |
| Stop rule | Missing rule, disputed identity, revoked access, or uncertain write result. |

## Can AI build a workflow from a simple request?

AI can draft the steps, people, tools and approvals needed for a request. Your team then checks the plan and tests it before it changes real systems. The plan also needs a route for missing information and failed steps.

Ask what happened in representative cases. One customer may have supplied an older form. Another may have supplied the current form, but a team matched it to the wrong account. A third may be waiting for an internal reviewer. The same “stalled” status can require different actions. Keep dates, sources, and disagreements attached to the evidence.

Reuse current tools where they already do the job. A form system may already validate file type. A CRM may remain the official account record. The AI layer can bring the relevant evidence together without replacing those systems. [Nodes Connector](/products#connector) can build and verify the required reads and actions. A documented API or successful login is not proof that a particular mapping or write works in the customer's environment; [the integration test](/blog/fast-integration-reads-as-risk) establishes that.


**Turn a goal into checked work**

1. **Goal**: Define the result, baseline, owner, and limits.
2. **Evidence**: Investigate relevant sources and exceptions.
3. **Workflow**: Reuse tools and draft steps with dependencies.
4. **Test**: Exercise normal cases, failures, and denied access.
5. **Authority**: Review consequential or newly scoped actions.
6. **Verified action**: Confirm the destination accepted the change.
7. **Outcome**: Measure the later business result separately.


Review authority before enabling consequential actions. Verify each external change, then measure the business outcome over the agreed period.

## Can AI create a team of agents for a specific task?

Yes. Specialist agents can split work such as checking records, comparing options and carrying out an approved action. Each needs a clear job and access limits. Some tasks need only one agent or an existing tool.

A fixed rule may be enough when the inputs and path are known. One agent may be useful when it has to inspect several records and choose the next allowed step. A bounded team of specialist agents may help when separate tasks need different tools or independent checks. A larger team adds handoffs, cost, and ways to fail, so its value needs to be demonstrated.

[Anthropic's agent-building guide](https://www.anthropic.com/engineering/building-effective-agents) distinguishes fixed workflows from agents that dynamically choose steps and tool use. An agent can begin from a person's goal or an agreed trigger. Proactive monitoring is one initiation mode, not a requirement for agentic work. The buyer's test is whether the selected design completes the task safely at an acceptable total cost.

For the illustrative case, the plan might read the current requirement, compare it with the customer's file, identify the correct owner, draft one request, ask for review when policy requires it, send through an allowed tool, and verify delivery. Put dependencies in order. The request cannot be sent until the identity and applicable requirement are resolved. If the rule is missing, the plan should stop and assign the exception.

## Test the plan where it can fail

Before enabling production actions, run ordinary and difficult cases. Include two similarly named accounts, a superseded document, a corrected requirement, a permission denial, a destination timeout, and a duplicated event. Define the expected response for each. A candidate workflow that succeeds only on a clean demonstration case is still a draft.

Test read and write authority separately. Confirm the identity that will execute each operation. An employee's view permission does not imply the connector's service account has the same limits, and a service account's broad access does not authorize the workflow to reveal restricted data. A customer policy may permit routine tasks under permission already given for that routine work and require a named reviewer for consequential or new scope. [Approval gates](/blog/what-is-an-approval-gate) should bind that review to the exact plan version.

A sandbox can test tool calls and failures without live effects. Read-only analysis can test current answers, though an answer shown to an operator may influence a decision. Live shadow evaluation can compare a candidate with the current process while keeping candidate outputs out of the action path. [The testing guide](/blog/shadow-evaluation-before-promotion) explains what each mode establishes.

## Verify work and measure results separately

After a permitted action, ask the destination for confirmation. A drafted message is an output. A recorded task or accepted message is a verified action. If the response is unknown, reconcile the destination before retrying so the system does not create duplicate work.

Then measure the business result over the agreed period. Did the customer start using the service sooner? Did repeated requests and customer effort fall? Compare with a credible baseline and note other process changes. A favorable outcome does not prove one AI step caused it, and a failed attempt is part of the record. Review proposed lessons before another workflow inherits them.

[Nodes AI FDE](/products#fde) helps clarify the goal, configure the solution, and test it. [Nodes Engine](/products#engine) uses connected company context to investigate, coordinate authorized work, and retain decisions and later outcomes. Connector supplies tested operations. A team of agents is an implementation choice. The result to buy is a defined business responsibility performed with evidence, current permissions, and a way to check what happened.

## Sources

- [Building effective agents](https://www.anthropic.com/engineering/building-effective-agents)

*Saad Bin Shafiq is the founder of Nodes, serving data-sensitive enterprises.*