Development8 min read

The AI Implementation Gap: Why Businesses Need Connected Workflows, Not More AI Tools

An AI subscription can help someone draft or research. Changing how work moves through a business takes more: connected information, clear responsibilities, reliable handoffs and a way to check the outcome. That is an implementation project.

By Menerai

The October story is about putting AI to work

On October 2, 2026, Anthropic announced a $100 million commitment to Claude Frontier Academy, aiming to train 10,000 Frontier Deployed Engineers by the end of 2027. Its program includes use-case selection, security review and handover, followed by a residency implementing a real project. The emphasis is on engineers who can take an idea into production inside a business.

AWS has also announced a $1 billion investment in a Forward Deployed Engineering organization. Its stated approach embeds engineers with customer teams to build systems around their data, processes and governance. These commitments signal how seriously providers are treating implementation; they do not establish what a smaller company should spend or how quickly its project will succeed.

Yesterday, October 6, GitLab announced its governed software factory direction. It reported 200% year-over-year growth in active users of agentic software development over the last three months on GitLab. The release emphasizes connected handoffs, policy, security and cost-and-impact reporting. That is vendor-reported platform growth, rather than a measure of adoption across all businesses.

Our takeaway for a business owner is practical: buying access to AI and implementing it into a working process are different decisions. If employees still copy information between systems, chase approvals and reconcile conflicting records, another subscription may leave the main bottleneck in place.

Canadian spending makes the outcome question more pressing

Float’s Canada’s AI Spending Snapshot 2026 reports roughly twelvefold growth in AI spending among businesses active from August 2024 to August 2026. The wider report draws on anonymized transactions from more than 10,000 Canadian businesses using Float. Its public summary also reports that 47% of businesses in its adoption comparison purchase at least one AI product, up from 27%.

Those are purchasing observations from a platform’s customer base, not a representative census of Canadian companies. They do not show how deeply customers integrated AI, how much time they saved or whether the spending paid off. A business can use the trend as a reason to review its own costs and outcomes without assuming that competitors have already transformed their operations.

Start with the work you can observe. Which tasks have become easier? Which outputs still need substantial correction? Where does someone take an AI result and manually enter it into another tool? That last handoff is often a useful place to investigate an integration, a review screen or a better shared record.

Four useful ways to describe the scope

Planning distinctions for an AI implementation project
ApproachHow work happensWhat needs defining
AI toolA person opens a tool and asks it to help with a task.Approved information, useful output and the person reviewing it.
AI automationA defined trigger calls AI for a narrow step.Input format, validation, failure handling and where the result goes.
AI workflowAI steps connect with business records, rules and approvals.Sources of truth, responsibilities and a complete path to the outcome.
AI agent or systemSoftware can choose steps and use tools toward a bounded goal.Permitted actions, stopping conditions, oversight and evidence of completion.

These are planning distinctions, not a universal product taxonomy or a ladder every company must climb. A person using an AI tool can already create value. A fixed automation can also be the right solution for years. More autonomy deserves a place in the scope only when it helps the job and the team can evaluate the result.

Our earlier guide to AI agents, custom software and websites helps choose the first investment. Here, the question is narrower: once you have chosen a workflow, what must be connected for it to work reliably from beginning to end?

Map the handoffs before selecting the model

Take one recent task and follow it through the business. For a project inquiry, that might mean a website form, an email notification, a CRM record, a qualification call, an estimate and an approval. Record who performs each step, which information they need and what tells the next person to begin.

Then mark where information is copied, missing or disputed. If the CRM and spreadsheet disagree about a customer’s status, adding AI does not decide which is authoritative. If nobody owns the approval queue, generating drafts faster can simply create a larger queue. Solve those process questions in discovery.

  • Trigger: what starts the work, and how is it identified?
  • Information: which records are authoritative and current?
  • Decision: what follows fixed rules, and what needs interpretation?
  • Approval: who reviews the result and what may they change?
  • Outcome: where is completion recorded and how are exceptions handled?

You may discover that the first project is ordinary integration work. Creating a CRM entry from a valid form submission does not necessarily need AI. Interpreting a varied project description may benefit from it. Keep explicit rules around the steps that already have explicit requirements.

What a connected workflow could look like

The following examples are hypothetical starting scopes, not Menerai client results. Each preserves a clear role for the team and separates draft preparation from business commitments.

For a contractor, an inquiry workflow could extract the requested work, location and timing from a submitted message, match those details against agreed service criteria and prepare a qualification summary. Missing details go to a review queue. A draft estimate could use an approved rate source and explicit calculation rules, with assumptions visible. A responsible estimator checks scope and pricing before anything reaches the customer.

For a professional-services firm, incoming documents could be assigned to the correct case, processed into proposed fields and shown beside their source passages for verification. A person confirms unclear or missing information before routing the work. Existing account permissions should determine which documents each reviewer can access.

For a sales team, approved data sources could help prepare lead summaries and suggest a priority for review. The CRM remains the authoritative record, and the team can inspect the reason for a suggestion. Sending outreach or changing account ownership is a separate action to define; it does not follow automatically from producing a useful summary.

For an operations team, the first need may be an internal dashboard showing work status, ownership and exceptions from existing systems. Once those records are dependable, AI could prepare a report explaining overdue items with links back to the evidence. Establishing the shared view may matter more initially than adding a conversational interface.

Plan what happens when the happy path fails

A demonstration usually shows a complete request and an available system. Production also includes duplicated submissions, unreadable attachments, expired connections and incomplete records. Define how the workflow behaves in those cases before it begins creating or changing business data.

For example, retrying a failed integration should not create a second customer record. A prepared estimate should not be marked as sent when delivery failed. An unreadable document should produce a visible exception rather than plausible replacement fields. These are application and integration requirements alongside the AI step.

Make the review queue usable: show the original request, the proposed result, the missing information and the next action. Give someone responsibility for that queue and a way to pause the automation. A clear internal tool can turn oversight into a manageable part of the workflow rather than another inbox employees have to search.

Make permissions and ownership part of the brief

Define what the system can read, propose and change separately. An inquiry summarizer may need access to service information and the submitted request, while an approved booking workflow needs a different connection. Enforce permissions in the application and integrations, with access scoped to the task.

Record which data will be sent to each provider and which vendor settings and agreements apply. Decide what belongs in logs and how long it should remain there. Keep a record of important changes, their source and any required approval. These decisions are easier when the first workflow has a limited, well-understood scope.

Name the person who owns the process after launch. They need a handover covering configuration, connections, exceptions, spend controls and how to request a change. A workflow that works only while its original developer watches every run has not reached a useful operational handoff.

Measure the completed job, including review effort

Before building, record how the task works today. Include task volume, time from arrival to completion, common mistakes and time spent checking or correcting the result. Choose a representative set of cases for the pilot, including known exceptions. Agree what would justify continuing before looking at the first demonstration.

A pilot scorecard without invented performance targets
QuestionEvidence to collect
Does it complete the intended job?Accepted outcomes and exceptions for the tested cases.
Does it reduce the team’s workload?Handling, review and correction time together.
Does it preserve quality?Missing details, incorrect fields and unsupported claims.
Is the cost reasonable?Model usage, integrations, support and human review.
Can the team operate it?Queue ownership, incident handling and a documented handoff.

A faster draft is useful only in context. If it takes longer to verify than the original task, investigate why. If the pilot works on simple cases but fails on common exceptions, narrow the scope or improve the workflow before increasing access. Recheck representative cases when prompts, models or integrations change.

Start with one workflow that deserves improvement

Choose a process with a recurring cost, a clear owner and an outcome you can inspect. Keep the first release small enough to test from trigger to completion. That may mean connecting existing tools, adding a review screen or building an internal application around a workflow that current products do not support well.

If a configured product meets the requirements, start there. Custom software is worth exploring when the data model, roles, integrations or user experience need something more specific. The discovery work should explain that choice and identify what needs ongoing maintenance.

Menerai’s custom software service covers discovery, internal tools, portals, integrations and workflow automation. A website can be the intake point, while the application handles what happens after an inquiry. Planning those together helps keep the customer journey connected to the team’s working process.

Already paying for AI but still doing the same work manually? Talk to Menerai about a software discovery sprint. We can help map the workflow and determine whether you need automation, an internal tool or custom software, with a practical first scope and a clear way to assess the result.

Sources & further reading

Have a website project in mind? Talk with the people who will design and build it.

Start a Project ↗

Keep reading

All articles ↗
Development

How Long Does It Take to Build a Business Website?

A useful timeline names the work, the decisions and the people responsible. ‘A few weeks’ means very little without knowing when the content is ready and what counts as finished.