Bernardo F. Nunes recently shared something that caught my attention: "There are essentially 4 ways to build an AI solution: 1. Assistants 2. Copilots 3. Autopilots 4. Agents." He added a line I keep coming back to: "The Agent is the one clients often want to build first... But it's also like the hardest place to start."

That framing is refreshingly real. Many teams (and buyers) are drawn to agents because they sound cool and futuristic. But Bernardo's point is practical: starting with agents can trap you in endless integration work, weeks of fixing mistakes, and a project that never ships. Meanwhile, simple assistants can deliver value on day one and become the foundation for a profitable AI journey.

In this post, I want to expand on Bernardo's four-part model, explain why agents are so seductive (and so hard), and offer a concrete way to choose the right starting point.

The 4 ways to build an AI solution (and what they really mean)

Bernardo's categories are a useful ladder of autonomy. As you climb, the system does more on its own, and your burden of reliability, governance, and integration rises.

1) Assistants: answer, draft, and explain

An assistant is the simplest pattern: the user asks, the model responds. The assistant may retrieve internal knowledge (RAG), follow a template, or apply a lightweight workflow, but it does not take actions on the user's behalf.

Typical assistant wins:

Internal knowledge helper (policies, product docs, troubleshooting)
Customer support draft replies
Sales enablement (call summaries, follow-up emails)
Analyst helper ("Explain this metric," "Summarize these notes")

Why assistants ship fast:

Minimal integration requirements
Clear human-in-the-loop control
Easier evaluation: you can score outputs, collect feedback, and iterate

"Put plenty in the simple Assistants that got users on day one." - Bernardo F. Nunes

That line captures the core advantage: assistants are adoption engines. They create daily use, generate real data, and expose the highest-leverage problems worth automating later.

2) Copilots: the AI works in your tool, with you

A copilot is embedded into a workflow where the user is already working (CRM, IDE, ticketing system, analytics tool). It suggests next steps, fills fields, or generates artifacts, but the user remains the decision-maker.

Copilot characteristics:

Context is richer (records, history, user intent)
UX matters more (side panels, inline suggestions, approval flows)
The model is constrained by business rules (validation, required fields)

Copilots are a strong second step after assistants because you can reuse the same core capabilities (retrieval, summarization, classification) but attach them to measurable workflow outcomes like time saved per ticket or increased form completion.

3) Autopilots: partial automation with guardrails

An autopilot executes predefined actions automatically in narrow, well-scoped scenarios. Think "if X, then do Y" with AI determining X or generating the content for Y.

Examples:

Auto-triage inbound tickets and route to the right queue
Auto-tag and summarize call transcripts
Auto-draft a response and send it when confidence is high (otherwise queue for review)

Autopilots require more rigor:

Strong logging and observability
Confidence thresholds and fallback rules
Clear ownership for exceptions and escalation

The upside is compounding returns. Once the autopilot is reliable in a narrow lane, it frees meaningful capacity and can be expanded gradually.

4) Agents: goal-driven systems that plan and act

Agents are typically described as systems that can decompose a goal into steps, use tools, call APIs, make decisions, and iterate until completion. They sound like a digital employee.

They are also where reality hits.

"I've seen projects start there and end up stuck in integration work forever." - Bernardo F. Nunes

The hard part is not prompting. It is everything around it: permissions, tool access, data quality, edge cases, failure modes, compliance, and the long tail of "what happens when this goes wrong?"

Why clients want agents first (and why teams struggle)

From a buyer's perspective, an agent promises maximum ROI: "Let it just do the work." It is an easy story to sell internally.

From a delivery perspective, agents multiply complexity:

Integration surface area explodes
An agent that "does things" needs access to systems of record (CRM, ERP, HRIS, ticketing, billing). Each integration brings authentication, rate limits, schemas, and governance.
Reliability becomes a product requirement, not a nice-to-have
If an assistant is wrong, a user can ignore it. If an agent is wrong, it can create a mess (bad refunds, incorrect emails, wrong database updates). You now need tight constraints, simulations, and robust rollback.
Evaluation is harder than people expect
It is easier to judge a single answer than to score a multi-step plan across tools. Agent success often depends on hidden states and external systems.
Exception handling is the long tail
The first demo works. The next 40 edge cases do not. Teams end up "spending weeks fixing mistakes" as Bernardo described, and shipping slips.

A practical way to choose the right starting point

When I apply Bernardo's ladder, I use a simple rule: start at the lowest autonomy level that still delivers meaningful value.

Ask these questions:

H3: Is the job-to-be-done primarily cognitive or operational?

Cognitive (summarize, explain, draft, search) usually starts as an assistant.
Operational (update records, trigger workflows) might move toward autopilot, but only after you prove the decision logic.

H3: What is the cost of being wrong?

Low cost: assistant or copilot with light review.
Medium cost: copilot with mandatory approvals.
High cost: autopilot with strict thresholds and strong guardrails.
Very high cost: agent only after you have mature controls and monitoring.

H3: Can you constrain the problem space?

Agents work best in bounded domains with clear tools and rules. If your process is ambiguous, undocumented, or different across teams, start with an assistant that helps standardize the work first.

H3: Do you have the foundations?

Before agents, you usually need:

Clean, accessible knowledge sources
Stable APIs and tool interfaces
Permissioning and audit logs
Error handling and human escalation paths

If these are missing, an "agent-first" plan is often just a hidden platform rebuild.

An incremental roadmap that matches Bernardo's advice

Here is a pattern that tends to ship:

Launch an assistant in 2 to 6 weeks
Focus on one high-frequency use case. Instrument usage and feedback. Learn what users actually ask.
Turn the highest-value actions into a copilot
Bring the assistant into the workflow tool. Add structured outputs, templates, and approvals.
Add autopilot for the narrowest repetitive tasks
Automate only when the decision boundary is clear. Use thresholds, sampling, and review queues.
Graduate to an agent where it truly fits
Only after you have trusted tools, observability, and exception handling. Start with a single objective and limited permissions.

The fastest path to "futuristic" often starts with something unglamorous that ships.

Closing thought

Bernardo F. Nunes is not arguing against agents. He is arguing against starting with them as your first bet. The teams that win tend to earn autonomy: assistants first, then copilots, then selective autopilots, and only then agents for well-bounded problems.

If you want a profitable AI journey, the question is not "What is the coolest thing we can build?" It is "What can we ship that users will adopt this week, and what foundations will that create for the next rung on the ladder?"

This blog post expands on a viral LinkedIn post by Bernardo F. Nunes. View the original LinkedIn post →