I find it useful to think about AI adoption in four overlapping layers. They are choices for organising work, not a maturity ladder. A ready-made tool can already be agentic, and a purpose-built application may combine tools, scheduled workflows, and agents. Start with the task and the access you actually have.
One hypothetical task: prepare a prospect brief
Consider a sales team that needs a brief covering prospect fit, supporting facts, open questions, and a suggested pitch angle. The same task can be approached in several ways; more layers do not automatically mean a better result.
Layer one — AI tools for everyday work
A person uses a ready-made tool, such as Claude Cowork, ChatGPT Work, or Gemini Spark, for a one-off brief from an approved source pack. They supply the criteria and check every important claim. Available connections, controls, and access differ; verify them before relying on the tool for the task.
Layer two — repeatable AI workflows
A recurring workflow could prepare briefs from new approved leads, follow reusable instructions, flag duplicates, and send results to a review queue. A schedule controls when it runs; a skill captures instructions; MCP can connect an AI application to tools and data. These building blocks require working access and output checks; their presence does not guarantee a successful run.
Layer three — AI-powered applications
A purpose-built lead application could give the team one place to set criteria, compare prospects, inspect source evidence, and approve pitch drafts. The product packages the task around shared users, permissions, and a consistent review experience. It still needs evaluation of research quality, operating cost, and usefulness.
Layer four — agentic AI
An agent-directed approach could choose follow-up searches when evidence is missing, compare conflicting information, and stop when the brief meets its agreed criteria. Its usefulness depends on whether that flexibility improves the reviewed result. It needs a clear stopping point rather than open-ended research.
Set boundaries before delegating
- Sources: use an approved list of company websites and public filings, or an authorised source pack. Record evidence and flag conflicts; ask before adding a restricted or private source.
- Runtime and spend: set an enforceable ceiling. Illustrative trial limits might be 15 minutes and MYR 5 per brief; these are hypothetical limits, not tool capabilities or achieved costs. If the system cannot enforce the limits, use a supervised run.
- Outreach: keep the result as an internal draft. Sending a pitch, changing a CRM record, or purchasing data requires explicit approval for that action.
My preference is the simplest combination that produces a dependable brief. Add recurrence, an application, or more autonomy when a specific need justifies it and the available controls support it.