AI adoption

How do I actually design and build an AI agent or workflow for a task?

Start with the workflow rather than the tool, because AI in Era 3 is not another layer of automation over an existing process. It reasons, coordinates and improves with use, which means the gain comes from redesigning the work rather than speeding up the version you already have. Design against an architecture instead of assembling tools one at a time, or you will automate fragmentation and move faster in the wrong direction. Split the work deliberately, giving AI the continuous analytical load and keeping judgment, tradeoffs and accountability with a named human. Own the design and outsource the execution. And prove the economics before you launch, because a workflow that only holds together when your best person intervenes is not finished.

Founders ask Collective 54 this 13 times in our records. It usually comes up after a first experiment worked in a demo and then failed to survive contact with real client work.

Start with the workflow, not the tool

The most common failure is starting from a tool and looking for something to point it at. The published position runs the other way, and the reason is specific to what AI is.

In earlier eras, technology executed instructions. It automated tasks, moved data and enforced rules, which made existing workflows more efficient without changing how work was designed. AI breaks that pattern. It reasons, recognizes patterns, coordinates across systems, predicts outcomes before they occur, and improves with use. That means it does not merely speed up work. It changes what work is possible.

So Era 3 is not about automating yesterday processes. It is about redesigning them. Firms that treat AI as one more tool bolted onto an already fragmented stack will automate chaos: they will move faster, in the wrong direction, while tech debt compounds.

The practical first step is therefore to write down how the work actually happens now, end to end, including the handoffs and the decisions, and then ask what the work would look like if intelligence were available at every step. Not which step to automate. What the redesigned process is.

Design against an architecture, or you will build debt

If Era 2 failed through tool sprawl, Era 3 fails through architectural incoherence, and the root cause is the same: the absence of a reference architecture for the specific business.

Greg Alexander describes that architecture as intelligence-first rather than tool-first, in five interdependent layers. The intelligence layer holds the capabilities that reason, predict and coordinate, interpreting data and informing decisions. The workflow layer defines how work actually happens, with the core workflows of selling, scoping, pricing, delivering and expanding deliberately re-engineered around intelligence rather than human memory and manual coordination. The data layer unifies operational, financial and delivery data so it can support reasoning and learning, not just reporting. The integration layer orchestrates communication across applications, AI systems and external tools so work moves end to end without brittle handoffs. The governance layer enforces security, access control, compliance and decision rights.

The important framing is that this is a design constraint rather than an implementation plan. Tools change and vendors get replaced. The architecture endures, and it is what makes tool selection intentional instead of reactive.

The cost of skipping it is not theoretical. Poor architectural decisions made early become hard to unwind once AI embeds itself into workflows. What starts as experimentation hardens into dependency, and eventually the cost of change exceeds the perceived benefit.

Split the work, and be specific about the human half

The division of labor that recurs across every role in the published material is roughly 80 percent to AI and 20 percent to a human, and the split is about judgment rather than effort.

AI takes the work that must happen continuously and without fatigue: monitoring, pattern detection, synthesis, forecasting, enforcement, documentation, memory of what was decided and why. This is the work that overwhelmed humans in earlier eras and was therefore deferred, done badly, or done heroically.

Humans keep judgment under ambiguity, tradeoffs where no clean answer exists, escalation and intervention, people leadership, and final accountability for outcomes.

When you design a specific workflow, make that split concrete rather than implied. Name the decisions a person must make, the point at which output is reviewed, who is accountable when it is wrong, and what evidence they will see in order to decide. A workflow where the human role is described as oversight, with no named checkpoint, is a workflow with no human role.

Own the design, outsource the execution

Technology is overhead in a professional services firm, and keeping it lean and outsourced remains correct. What changes in Era 3 is not whether you outsource but what.

Generalist managed service providers are built to execute against known patterns. They optimize for stability, consistency and cost control, and they are good at running infrastructure. They do not design AI-native architectures, they do not re-engineer how a professional services firm sells, scopes, prices, delivers and expands work, and they do not hold a reference architecture for this business model. That capability does not exist in the outsourcing market.

So the line is drawn differently. The firm owns the architecture and how core workflows are re-engineered around intelligence. Provisioning, security, access, uptime, integrations and support stay outsourced, executed against the firm design. The outsourcer becomes an operator rather than an architect.

The alternative is outsourcing the thinking, which is where the model breaks.

Prove the economics before you launch

A workflow is a service design, and it can be stress-tested the same way.

Model the cost to serve across its human, AI and tooling components before you commit, rather than discovering the economics afterwards. Validate that the skills the design assumes are actually available and can scale. Work out the realistic cycle time from start to finished outcome. Define how quality is controlled and by whom. Identify the predictable failure points, and make sure you will hit them before a client does. And decide explicitly which parts are performed by people and which by systems, rather than discovering the answer mid-engagement.

The test worth adopting is blunt: a service that cannot be delivered without heroics is not a finished design. If the workflow holds together only when your strongest person intervenes, you have built a dependency rather than a system.

One accounting point follows. Delivery tooling and AI usage belong in the cost of the work, inside contribution margin, rather than in general overhead. Otherwise your margin picture drifts quietly as the mix shifts from people to systems, which is exactly the shift you are trying to measure.

What we do not prescribe, and why

Collective 54 publishes a position on the design decisions above. It does not publish a recommended build stack, and this answer will not invent one.

Specific models, platforms and frameworks change faster than any durable guidance can hold, and they are not where the advantage sits. Two firms can use identical tools and get opposite results, because the difference is whether the workflow was redesigned and whether the architecture is coherent. Anyone handing you a definitive stack recommendation is handing you a snapshot with a short shelf life.

If you want a starting point that will still be right in a year, it is the sequence rather than the software: map the workflow, design it against the five layers, define the human checkpoints, model the cost to serve, then choose tools to fit that design and expect to replace them.

When this answer flips

If the process is not yet defined by humans, do not automate it. You will encode the confusion and make it faster and harder to see. Define the work first, even roughly, then redesign it.

If the task is genuinely one-off, a designed workflow is overhead you will not recover. The same logic that says one-off client projects make a firm impossible to staff correctly applies internally: the value of a workflow comes from repetition.

And if you operate in a heavily regulated or conservative market, sequence the governance layer first rather than last. The same essay that argues for moving fast also argues that ungoverned AI usage, unclear data lineage and brittle integrations are exactly what makes a firm look risky to a sophisticated buyer later.

The short answer

Begin with the workflow rather than the tool, because the gain in Era 3 comes from redesigning how work happens rather than accelerating the current version of it. Design against a reference architecture with five layers, intelligence, workflow, data, integration and governance, and treat it as a constraint on every future tool decision rather than a project plan. Make the division of labor concrete: give AI the continuous monitoring, synthesis, forecasting and memory, and keep judgment, tradeoffs, escalation and accountability with a named person at a named checkpoint. Own the architecture inside the firm and leave provisioning, security, integration and support with an outsourcer executing against your design, because generalist providers run infrastructure well and do not architect intelligence. Prove feasibility and cost to serve before launch, count AI and tooling inside contribution margin, and treat any workflow that needs heroics as unfinished. Choose tools last and expect to replace them.

Related questions

Questions founders ask next

Where should I start when building an AI workflow?

Start by writing down how the work actually happens today, end to end, including handoffs and decisions, and then ask what the process would look like if intelligence were available at every step. The question is not which step to automate. In Era 3 the gain comes from redesigning the work, because AI reasons, coordinates and improves with use rather than simply executing instructions. Firms that bolt AI onto an existing fragmented process automate chaos and move faster in the wrong direction.

Should we build AI tools ourselves or buy them?

The more useful split is not build versus buy but design versus execution. The firm should own the architecture, meaning how core workflows such as selling, scoping, pricing, delivering and expanding work are re-engineered around intelligence. Provisioning, security, access, uptime, integrations and support should stay outsourced and execute against that design. Generalist managed service providers are built to run infrastructure against known patterns, not to architect intelligence for a professional services business model, so outsourcing the design outsources the part that creates the advantage.

Why do AI projects in professional services firms fail?

Usually because they are assembled rather than designed. Without a reference architecture, one tool lands in sales, another in delivery and a third in operations. Each works in isolation and together they create complexity: workflows fracture, data diverges, exceptions multiply, and the founder becomes the glue again, only now the systems are moving faster than anyone can manage. The second common cause is an undefined human role, where a workflow claims oversight without naming a checkpoint, a decision or an accountable person.

Which AI tools and models should we standardize on?

Collective 54 publishes a position on the design decisions rather than on a recommended build stack, and this answer will not invent one. Specific models and platforms change faster than durable guidance can hold, and they are not where the advantage sits: two firms can use identical tools and get opposite results depending on whether the workflow was redesigned and whether the architecture is coherent. Choose tools last, to fit a design you have already settled, and expect to replace them.

Sources: Greg Alexander, The AI-Native Boutique Firm (Advantage Books, January 2027), specifically The AI IT Manager for why AI is different from automation, why Era 3 is about redesigning workflows rather than automating existing ones, the five-layer AI technology reference architecture of intelligence, workflow, data, integration and governance, the argument that architecture is a design constraint rather than an implementation plan, the risks of automating chaos and irreversible tech debt, and the division between owning the design and outsourcing the execution; The AI Service Design Manager for modeling cost to serve across human, AI and tooling components, stress-testing delivery feasibility, cycle time, quality control and failure points before launch, and the test that a service requiring heroics is not a finished design; The AI Operations Manager for the division of labor between continuous governance work and human judgment, escalation and accountability; and The AI Engagement Manager for the definition of contribution margin that places delivery tooling and AI costs inside the cost of the work. Greg Alexander, The Boutique: How to Start, Scale, and Sell a Professional Services Firm (Advantage, 2020), chapter 11 for why one-off work cannot be staffed or systematized. Collective 54 does not publish a recommended AI build stack, and the absence of tool-level prescription in this answer is deliberate and stated in the copy.

Bring your firm's version of this question.

Collective 54 is the private community for founders and executives of boutique professional services firms between $5M and $50M in revenue. Members work these answers against their own numbers.

More answers in the Answer Library.