Forcoda Team Spotlight: Meet our CTO – Marc Asselin

Marc Asselin started building AI when “doing AI” meant a neural network that took weeks to train and a 2% improvement was worth celebrating. No hype. No boardroom mandates. Just hard problems and people willing to sit with them.

Three decades on, Marc is Forcoda’s CTO — and he’s spent that career building AI in places where a wrong answer carries weight. Clinical decision support, where a false negative could mean a missed sepsis diagnosis. Defense and intelligence platforms, where a confidently hallucinated output can’t reach a partner without a human checkpoint. U.S. fintech infrastructure running under bank-grade regulatory scrutiny.

That track record shapes how he approaches every Forcoda engagement. Marc doesn’t open with the model. He opens with the workflow, the failure modes, and the scoped autonomy appropriate to each decision. “Production-ready” isn’t a benchmark score to him – it’s whether you’d stake your operation on the system’s output on a Tuesday at 3 a.m. when nobody’s watching.

We sat down with Marc to highlight what our enterprise clients are actually asking right now: where agentic AI is genuinely ready, where it isn’t, the mistakes that quietly kill well-funded initiatives, and the one boardroom assumption he’d most like to overturn.

What drew you to AI before it was a boardroom conversation - and what has surprised you most about how the field has evolved?

Honestly, it was the math and the problems, not the hype. Back then, there was no hype. You worked on AI because the problems were genuinely hard and the tools were genuinely interesting, neural nets that took a week to train, expert systems that needed hand-coded rules, optimization problems where you celebrated a 2% improvement.
What’s surprised me most isn’t the capability jump. I expected that eventually. What surprised me is how little the operational discipline has scaled with the capability. We have models now that would have been considered science fiction in 2010, and organizations are still deploying them with less rigor than they’d apply to a CRM migration. The tech got 1000x better. The thinking around how to actually run it in production hasn’t kept pace.

What's the most common mistake organizations make when they start an AI initiative?

They start with the model instead of the workflow. Someone in the boardroom saw a demo, now there’s a mandate to “do AI,” and three months later, there’s a pilot that technically works but doesn’t change anything because nobody mapped what humans were actually doing, where the friction was, or what would have to be true operationally for the AI to matter.

The second mistake is treating AI like software. It’s not. Software is deterministic. AI is probabilistic. If you deploy a probabilistic system with deterministic governance, meaning no checkpoints, no scorecards, no fallback paths, you’re going to have a bad time. I’ve watched well-funded initiatives die because nobody designed for the failure modes.

What does "production-ready AI" actually mean, and why do so many AI projects stall before they get there?

Production-ready means the system is reliable enough that you’d stake your operation on its output, and you have the instrumentation to know when it’s drifting before your users do. That’s it. It’s not about benchmark scores. It’s about whether you can run it on Tuesday at 3 AM when nobody’s watching and trust what comes out.

Projects stall because most teams confuse a working demo with a working system. A demo handles the happy path. Production has to handle the 5% of inputs that are weird, the 1% that are adversarial, and the 0.1% where the model confidently hallucinates something that could get someone hurt or sued. I’ve had agents confabulate vessel histories that sound completely plausible, entirely wrong. If that goes to a customer or a defense partner without a human checkpoint, you don’t get a second chance.

The bridge between demo and production is unglamorous work: evals, scorecards, human-in-the-loop design, fallback logic, observability. Most organizations underinvest in all of it because none of it looks impressive in a board deck.

How does high-stakes experience change the way you approach lower-stakes enterprise problems?

It makes you paranoid in a useful way. When you’ve built systems where a false negative means someone misses a sepsis diagnosis, you stop thinking about accuracy as a single number. You start thinking about which errors you can tolerate, which you absolutely cannot, and what the cost asymmetry looks like.

That mindset transfers. Even on a “low-stakes” enterprise problem, say, an agent triaging support tickets, there are still errors that are recoverable and errors that aren’t. Sending a customer the wrong refund amount is recoverable. Auto-responding to a regulator with hallucinated information is not. Most teams treat all errors as equivalent. They’re not. The high-stakes work teaches you to be specific about which failures you’re designing against and to build the checkpoints exactly where the asymmetry lives.

In fintech and banking, what's your approach to threading the innovation-vs-risk needle?

You don’t thread it. You design around it. The mistake is treating compliance as a constraint that limits AI, when really it’s a forcing function that makes AI deployable. If you can’t explain a decision, you can’t ship it in a regulated environment, so you build systems where explainability is part of the architecture, not bolted on at the end.

Practically, that means scoped autonomy. Agents handle the reversible, well-bounded work. Humans handle the consequential decisions and approve anything that crosses defined thresholds. You get speed where speed is safe and oversight where oversight matters. Banks that try to fully automate consequential decisions either get bitten by regulators or by the model itself. Banks that refuse to automate anything get eaten by competitors who figured out scoped autonomy.

How would you explain agentic AI to a skeptical-but-curious CEO?

A regular AI tool waits for you to ask it something and gives you an answer. An agent has a goal, a set of tools, and the autonomy to take steps toward that goal without being prompted at every turn. Think of it as the difference between a calculator and an analyst. The calculator is faster than you. The analyst is faster than you, and you can hand them a problem and walk away.

The skepticism is healthy. Agents fail in ways that single-shot AI doesn’t, because they compound errors across steps. But that’s an engineering problem, not a reason to dismiss the category. The CEO question isn’t “is agentic AI real?” It’s “what’s the smallest, most contained workflow in my business where I can prove this out before I commit to it broadly?”

Biggest untapped opportunity for agentic AI in enterprise over the next 18-24 months - and which industries should move fastest?

The biggest opportunity is internal operations work that nobody wants to do, vendor management, contract review, compliance monitoring, internal reporting, the connective tissue between systems. It’s high-volume, rule-heavy, and currently absorbing enormous headcount that produces no competitive advantage. Agentic systems eat this work cleanly because the tasks are bounded and the failure modes are recoverable.

Industries that should be moving fastest: financial services back-office, healthcare administration, logistics, and any government-adjacent sector where the workforce is shrinking faster than the workload. Defense and intelligence too, but those move at their own pace for good reasons. The ones that should be cautious are anything where a single agent error has unbounded downside, clinical decision-making, autonomous weapons, fully automated trading without circuit breakers. Move fast where errors are recoverable. Move carefully where they’re not.

When a CIO or CTO engages Forcoda on an AI readiness assessment, what do they typically find out that they weren't expecting?

Usually, their data is in worse shape than they thought, and their organizational readiness is in better shape than they thought. The data problem is almost universal, fragmented, inconsistently labeled, and locked in systems that don’t talk to each other. They knew it was bad. They didn’t realize it was the bottleneck.

The pleasant surprise is that their people are typically further along than leadership assumes. There are pockets of teams already experimenting, already running their AI workflows, already past the curiosity phase. The work isn’t convincing the organization to care about AI. It’s giving the people who already care a coherent framework so their efforts compound instead of fragmenting.

What does a successful client engagement look like - not in deliverables, but in what the client can do differently afterward?

They stop asking “should we use AI for this?” and start asking “what’s the right level of autonomy for this workflow, and where do the checkpoints go?” That’s the shift. They’ve internalized that AI isn’t a product decision, it’s an operational design decision, and they have the vocabulary and the frameworks to make those decisions themselves without needing a consultant in the room.

The other marker is that they start shipping. Successful engagements end with the client in motion, pilots running, scorecards in place, the next three workflows already mapped. If we leave and everything stops, we failed. If we leave and they’re accelerating, we did the job.

The one thing you'd want every C-suite leader to walk away believing about AI that they probably don't believe today?

You don’t need a team. You need a system.

The default assumption in most boardrooms is that AI transformation requires hiring a Chief AI Officer, a data science org, an internal platform team, and the whole apparatus. Sometimes that’s right. Often it isn’t. What you actually need is a clear understanding of your workflows, disciplined human checkpoints where they matter, and the willingness to let well-designed agents do the work in between.

If you’re about to kick off your project and want a second opinion on where you should start, we’d be happy to take a look. We do free 30-minute discovery consultations for founders who want a realistic read on what they’re taking on.

Book a free Discovery Call →

We’ve helped 50+ teams scope and build their MVPs. Book a free 30-minute call and get an honest assessment before you commit to a build.

You want to build a product and are not sure whether you need a prototype, MVP, or proof of concept? Hire a team? Talk to Forcoda’s experts — we help founders figure out where to start and are there to support them through the whole process.