Build the systems your next chapter needs.

Start with work that already has a clear owner, repeatable input and visible cost. The best first agent is rarely a fully autonomous salesperson. It is usually a careful assistant that assembles evidence, drafts an action and asks a person to approve it.

1. Daily reporting agent. Let it collect spreadsheets, emails and forms into one dated summary. Define the metric dictionary first: what counts as an order, a closed case or an overdue task? Require source links and a missing-data warning. A manager should still approve the final message.

2. Customer follow-up agent. Trigger it after a quote, service visit or missed call. It should use approved templates, account history and a stop rule for sensitive cases. Have a human approve outbound messages until you trust its tone and routing.

3. Knowledge answer agent. Index the current SOPs, product notes and HR policies. Make every answer cite a source and say “I don't know” when evidence is weak. Assign one person to retire old documents.

4. Exception agent. Watch for late collections, stalled approvals or safety actions. It should group exceptions by owner, financial exposure and deadline, then escalate only when a rule is met.

5. Lead research agent. Gather public signals, score fit against your actual ideal customer profile and prepare a concise brief for a salesperson. Do not let an unreviewed model make claims about a prospect.

Pick one workflow. Measure its current time, error rate and escalation delay for two weeks. Run the agent alongside the current process, compare outputs and expand only after a real owner signs off. In India, plan for WhatsApp habits, spreadsheet handoffs, multilingual inputs and patchy field connectivity from the start.

Buying is usually right when the work follows a common pattern: invoicing, basic CRM, payroll or scheduling. You get mature support and a shorter setup. Start by writing down the workflow, then test a product with real data and the people who will use it. A feature checklist alone misses the slow handoff that causes the actual cost.

Custom software becomes sensible when the workflow itself is your advantage or when existing tools force a costly workaround. Examples include distributor rebate rules tied to territory and product mix, a plant safety process that must work offline, or a service operation where several teams own different parts of one customer promise. If the process is stable enough to describe but too distinctive for a standard product, custom may have a stronger case.

Calculate total cost over a realistic horizon. Include licences, integration, data migration, change management, administrator time and the cost of work left outside the product. For custom, include design, build, hosting, maintenance, model usage, evaluation and security review. Avoid comparing only a subscription fee with a build quote.

Ask three questions before you commission anything. First, which decision or handoff will be materially better? Second, can the needed data be accessed lawfully and reliably? Third, who will own the process after launch? If those answers are vague, buy a simple tool or run a short discovery sprint first.

A good hybrid path is common: keep commodity systems for records and build a narrow intelligence layer around them. The layer can read approved data, generate recommendations, route approvals and write back only with clear permission. Demand exportable data, documented interfaces, a rollback plan and a named operating owner. Your first version should prove one useful workflow, not reproduce an entire software category.

Describe a Tuesday, not a vision statement. Who starts the work? What arrives, in what format, and where? What judgment is made? What happens when the input is missing or wrong? A studio can make a convincing demo from a clean sample. Production value appears when the system survives the inconvenient cases.

Bring three real examples: a normal case, a difficult case and a case that should be rejected or escalated. Remove personal data before sharing. Add the current SOP, a sample output and the person who can decide whether the result is correct. If there is no agreed answer, say so. The build may first need a decision rule, not a model.

State the outcome in operating language. “Reduce the time from incoming report to manager review” is stronger than “add AI.” Define baseline and target, but keep the target provisional until the team measures real data. Say who will use the system each day and who owns it when the project ends.

List the boundaries: data sources, user roles, approvals, audit needs, retention rules, languages, offline requirements and integration access. For each external system, name an owner who can grant access. Include a budget band and a deadline if one exists; these guide scope and sequencing, not just pricing.

Ask the studio to show a working slice early. The first review should use your actual process and realistic edge cases. Request a visible test plan, a fallback for model uncertainty, documentation and code and data ownership terms. At handover, your team should be able to run the workflow, see why a decision was made, correct bad outputs and know who to call when something fails. The brief builder below turns these points into a starting document you can copy.