Maacdow — AI workflows and agents that hold up in real work

Maacdow is a Montréal studio that builds AI workflows and agents for growing businesses, and repairs the ones that stopped working after the demo.

Discuss a project See how we work

Start with one useful workflow. Build from there.

Four ways we take work off your team.

Each engagement starts from a specific process, not from a technology. We agree what the system should do, how you will know it works, and who stays in control.

A fixed sequence with a review step.

The situation: Requests arrive by email, form and phone. Someone copies details between tools, chases missing information and writes the same reply for the tenth time this week.
What you get: A mapped workflow connected to the tools you already use. AI handles the reading, sorting and drafting. A person decides wherever a decision matters.
For example: Incoming requests become structured records, with a drafted follow-up waiting for approval.

Intake parsing
Classification
Document extraction
Drafting
Approval queue
Audit log

One agent, a few tools, a way out to a person.

The situation: Some tasks need more than a fixed sequence: looking something up, choosing the next step, using two or three systems to finish the job.
What you get: An agent scoped to one job, with defined tools, clear limits on what it may do alone, an escalation path to a person, and a log of every action it takes.
For example: An agent prepares a quote from a request, checks it against your price list and hands it to a team member to send.

Scoped tools
Permission limits
Escalation path
Action log
Evaluation set

Find the broken link, patch it, prove it.

The situation: You already have a chatbot, an automation or a pilot. It worked in the demo. Now it gives inconsistent answers, breaks quietly, or nobody trusts it enough to use it.
What you get: A written diagnosis of what is failing and why, a prioritised fix list, and the fixes themselves: prompts, retrieval, data, integrations or the workflow around the model.
For example: A support assistant that contradicts your policies is rebuilt around approved sources, with a test set designed to catch regressions before customers do.

System audit
Failure log
Test set
Retrieval fixes
Prompt restructuring
Handover notes

Lanes by difficulty, and a second route.

The situation: The system works for ten users. At a few hundred it slows down, costs climb, and one provider outage stops the whole process.
What you get: Evaluation suites, tracing and monitoring, cost and latency tuning, fallbacks for provider failures, and a runbook your team can follow.
For example: Routine requests go to a smaller model and the larger one is kept for hard cases, with quality measured before and after.

Evaluation suite
Tracing
Alerts
Model routing
Caching
Fallback provider
Runbook

It worked in the demo. Then real users arrived.

AI failures often involve more than the model: missing tests, unclear scope, stale data and integrations nobody owns. Tick what sounds familiar and see where we would start.

40%+

of agentic AI projects will be cancelled by the end of 2027, Gartner predicts, citing escalating costs, unclear business value or inadequate risk controls.

Gartner press release, June 25, 2025

What sounds familiar?Answers change from one day to the next, and nobody can say why.The assistant states things that are not in your documents.An automation fails silently and the team finds out from a customer.Usage costs grew faster than usage.Every prompt change fixes one case and breaks another.The person who built it has left, and nothing is documented.

Where we would look first

Tick one or more symptoms above. The likely causes appear here, in the order we would check them.

No fixed test set
Changes are judged by trying a few examples and seeing how they feel.
First checkCollect real examples with known good answers and score every change against them.
Unpinned model or settings
The provider updates the model, or sampling settings allow wide variation.
First checkPin the model version and review temperature and related settings.
Retrieval returns the wrong material
Outdated, duplicated or irrelevant passages are handed to the model.
First checkFor each failing question, inspect what was retrieved before touching the prompt.
No grounding rule
Nothing stops the model from answering out of general knowledge.
First checkRequire a citation for every claim and route unsupported questions to a person.
No tracing or alerts
Errors are swallowed and nobody is told, so problems surface late.
First checkTrace every run, then alert on failures and on unusual silence.
Brittle integration
An API changed, a token expired, or a field moved in a connected tool.
First checkReview authentication expiry, error handling and retries at each connection.
One large model for everything
Routine requests use the most expensive model with long prompts.
First checkMeasure cost by task type, route routine work to a smaller model, and cache repeats.
One prompt doing too many jobs
A single prompt handles classification, policy, tone and formatting at once.
First checkSplit it into steps that can each be tested on their own.
No documented ownership
Accounts, keys and prompts live with one person or in one inbox.
First checkInventory accounts, keys, prompts and data flows, and move them into your name.

What a repair engagement produces

Diagnosis: A plain-language report on what fails, how often, and the likely causes.
Test set: Real examples from your process, so every change can be checked against them.
Fixes: Applied in priority order, each one measured against the test set.
Handover: Documentation, access and ownership recorded, so your team can keep running the system after the project ends.

From a useful idea to a system your team can use.

Timelines and estimates follow discovery. We do not quote a project before we understand the workflow.

Understand the workflow
We sit with the people who do the work and trace where time is lost and where mistakes happen.
Deliverable
Workflow map
Define a focused pilot
One task, a clear boundary, and a shared definition of what "working" means before anything is built.
Deliverable
Pilot scope and success criteria
Build and evaluate
We build against real examples from your process and test the system the way your team will use it.
Deliverable
Working system with evaluation results
Launch and improve
Your team takes over with documentation and training. We stay available if you want ongoing support.
Deliverable
Handover documentation and support options

What this looks like in practice.

Two scenarios of the kind we take on. Select a step in the proposed system to see what happens there and how it is checked.

Illustrative workflow, not a client case study

Inquiry triage for a service business

New inquiries land in a shared inbox. One coordinator reads, re-types and replies. Busy days mean slow answers.

Today

Inquiry arrivesShared inbox
Coordinator reads itBy hand
Re-types the detailsInto the booking tool
Writes a replyFrom scratch
SendsWhen there is time

Proposed

Read and classify

AI step

What happens

The request type, urgency and any missing details are identified.

How it is checked

Compared against a hand-labelled sample before launch, and spot-checked afterwards.

Inquiry arrives (Input)
What happens: Messages from the inbox and the website form enter one queue.
How it is checked: Every message is logged with a timestamp, so it can be traced if it goes missing between tools.
Read and classify (AI step)
What happens: The request type, urgency and any missing details are identified.
How it is checked: Compared against a hand-labelled sample before launch, and spot-checked afterwards.
Create record (Automatic)
What happens: A structured record is created in the tool the team already uses.
How it is checked: Required fields are validated. Incomplete records are flagged, not guessed.
Draft reply (AI step)
What happens: A reply is drafted from approved templates and the details of the request.
How it is checked: Drafts are scored against past replies the team was happy with.
Approve and send (Person decides)
What happens: The coordinator reads the draft, edits it if needed, and sends it.
How it is checked: Edits are recorded. Frequent edits show where the drafts need work.

What we would measure

Handling time per inquiry
Share of drafts sent without edits
Time to first response

Repairing an internal knowledge assistant

Staff ask an assistant about procedures. It sometimes answers from outdated documents and cites nothing, so people stopped relying on it.

Today

Staff questionChat
Searches everythingOld and new documents
Answers without a sourceAI step
Staff double-checkBy hand, or not at all

Proposed

Permission check

Automatic

What happens

The search is limited to documents this person is allowed to read.

How it is checked

Tested with accounts at each access level before launch.

Staff question (Input)
What happens: The question arrives with the identity of the person asking.
How it is checked: Questions are logged, so recurring gaps in the documentation become visible.
Permission check (Automatic)
What happens: The search is limited to documents this person is allowed to read.
How it is checked: Tested with accounts at each access level before launch.
Retrieve sources (Automatic)
What happens: Only current, approved documents are searched. Archived versions are excluded.
How it is checked: For each test question, we inspect which passages were retrieved.
Answer with citations (AI step)
What happens: The answer quotes its source and links to the passage.
How it is checked: Scored on a fixed test set: is the answer right, and does the citation support it?
Escalate if unsure (Person decides)
What happens: Questions the documents cannot answer go to a named owner instead of being guessed.
How it is checked: Escalations are reviewed to decide which documents need writing or updating.

What we would measure

Answer accuracy on a fixed test set
Share of answers with a valid source
Weekly active staff

What you can hold us to.

We will

Start with one defined task, and widen scope only once it is dependable.
Put a person at every decision that touches customers, money or commitments.
Write down how success will be measured before we build.
Keep accounts, keys and data in your name.
Hand over documentation written for the people who will run the system.
Tell you when a simple rule or a spreadsheet would do the job better than AI.

We will not

Quote a price or a timeline before we understand the workflow.
Ship anything we have not tested against real examples from your process.
Promise a saving or a result we have no way to measure.
Build something only we can maintain.

A small studio in Montréal, by design.

Maacdow is a hands-on AI implementation studio. The people who scope your project are the people who build it, so less gets lost between the first call and the work.

We work with owners and operations leaders at small and midsize businesses who want practical results from AI: less repetitive work, fewer dropped requests, and systems the team trusts enough to use.

Based in: Montréal, Québec
Languages: English and French
Works with: Small and midsize businesses
Local time

Before you get in touch.

What does a first engagement look like?

It starts with a conversation about one process you want to improve or one system that is not working. If there is a fit, we run a short discovery to map the workflow and then propose a focused pilot with a written scope.

Can you fix an AI system someone else built?

Yes, that is a core part of our work. We need access to the system, its configuration and some real examples of where it fails. The first deliverable is a diagnosis, so you can decide what to fix before committing to the fixes.

Can you work with the tools we already use?

Usually, but it depends on what each tool exposes. We assess integrations during scoping and tell you plainly if something cannot be connected reliably.

How are scope and pricing agreed?

After discovery, you receive a written scope with deliverables, success criteria and a price. We do not publish rates because they depend on the workflow, the integrations and the level of support you want.

How is AI output reviewed?

Two ways. During the build, we test against real examples from your process. In operation, the workflow includes review steps wherever a person should approve the result. Where those steps sit is your decision.

What happens to our data?

That is agreed before any data moves: what the system reads, which providers process it, where it is stored and for how long. If a requirement cannot be met with a given provider, we say so and propose an alternative.

What does handover include?

Documentation written for your team, a walkthrough, the evaluation set, and a record of accounts, keys and ownership. The system and its accounts stay in your name.

Do you offer ongoing support?

Yes, if you want it. Support can cover monitoring, adjustments as your process changes, and periodic re-evaluation. The terms are agreed separately from the build.

What would you like to take off your team’s plate?

Tell us about one process you would like to improve, or one AI system that is not doing its job. A few sentences are enough to start.

AI thatholds upon a busyTuesday.

AI workflows and automation

AI agents

AI repair and rescue

Scale and reliability

It worked in the demo. Then real users arrived.

Where we would look first

No fixed test set

Unpinned model or settings

Retrieval returns the wrong material

No grounding rule

No tracing or alerts

Brittle integration

One large model for everything

One prompt doing too many jobs

No documented ownership