AI Is Not the Bottleneck. Context Is.

In 30 Seconds

The models are good. Really good. Claude, ChatGPT, Gemini – any of them can handle most business tasks if you set them up right.

Yet most companies are stuck.

Not because the technology isn't ready. Because the context of their specific business processes never reaches the model.

The Context Problem

Imagine you want to automate invoice processing.

The model can read invoices. It can extract numbers. It can even spot anomalies. Technically, this is solved.

But does the model know that:

• Invoices from Supplier X always get 2% early payment discount, but only if paid within 14 days?
• "Approved" in procurement means something different from "approved" in accounting?
• Amounts over €10,000 always require C-suite signature – except for recurring contracts?
• Supplier Y changed their invoice numbering last quarter and the old format still runs in parallel?

No. The model doesn't know any of that. And it's not documented anywhere.

That knowledge lives in the head of the person who's been processing invoices for three years.

Why Documentation Doesn't Solve It

The obvious answer: "Then let's just document everything."

Sounds good. Doesn't work.

First: Process knowledge is tacit. The person who knows the process often doesn't know what they know. They make decisions based on experience and intuition, not a rulebook. Ask them for the rules and they'll tell you maybe 60%. The rest they just do – without thinking about it.

Second: Processes change constantly. Today's documentation is tomorrow's technical debt. No company manages to keep process documentation permanently up to date. Anyone who claims otherwise is lying – or hasn't automated real processes yet.

Third: Translating process knowledge into technical specifications is lossy. Between "I know how the process works" and "here's a prompt that captures it," nuances get lost. Every time.

The Classic Approach Fails

Here's how it goes in most companies:

1. The business team has a problem
2. They file a ticket with IT
3. IT (or an external vendor) builds a solution
4. The solution works – but only 80% of the time
5. Iterations, meetings, refinements
6. After 3 months the solution is "done" – and already doesn't match the process because it changed in the meantime

The problem isn't incompetence. It's a communication problem. Knowledge has to transfer from Head A to Head B, and every transfer loses something.

"Every interface between the process expert and the builder is a point where context gets lost."

The Thesis: Process Owners as Builders

We believe: the people who own the process should be the ones building the AI solution.

Not alone. Not without support. But they should be in the driver's seat.

Why?

• They have the context. All of it. Every edge case, exception, and "we've always done it this way" rule.
• They spot errors instantly. When the model makes a wrong call, they see it – because they know what the right one looks like.
• They can iterate. Instead of writing a 20-page requirements doc, they test directly and adjust.
• They stay accountable. No handoff, no "IT built it that way." The process and the automation belong together.

What Changed: Vibe Coding and No-Code AI

Two years ago, this thesis would have been unrealistic. Not everyone can code. Not everyone should.

But the tools have fundamentally changed:

Vibe Coding lets you build software by prompt. You describe what you want – and tools like Lovable, Cursor, or Claude Code translate it into working code.

monday.com with AI Blocks and Workflows lets you build AI automations directly in your existing workspace – without a single line of code.

Make.com and n8n connect APIs visually and let you create complex automations via drag & drop.

This means: the technical barrier has dropped dramatically. What remains is the context barrier – and only the process owner can overcome that.

What This Looks Like in Practice

Example 1: Support Ticket Triage

Before: IT builds an ML model for ticket classification. Trained on historical data. Result: 70% accuracy. Not bad, but not good enough for production.

After: The support team lead builds an AI agent with monday.com AI Workflows. She knows the rules: "Anything with 'server down' is P1. Anything from Client X is always at least P2. Password resets can wait." She formulates the rules as a prompt. Result: 95% accuracy on day one.

The difference? Context.

Example 2: Proposal Generation

Before: Sales asks IT for a tool. IT evaluates for 6 months. Picks an enterprise solution. Implementation takes another 4 months. Sales doesn't use it because it doesn't fit their process.

After: The sales lead builds a proposal tool with Lovable over a weekend. It pulls client data from monday.com, generates copy with Claude, and creates PDFs. Not perfect. But it gets used – and gets better every week because he iterates on it himself.

Example 3: Reporting

Before: Leadership gets a report PDF every Monday. Manually created, 4 hours of work. Data copied from three different systems.

After: The ops manager builds a Make.com flow that pulls data from monday.com, HubSpot, and accounting, has Claude summarize it, and sends it automatically. Effort after setup: 0 hours.

The Role of IT and External Consultants

This doesn't mean IT teams or external consultants become obsolete. Quite the opposite – their role evolves:

From builders to enablers:

• They provide infrastructure (APIs, access rights, security)
• They train process owners on the tools
• They review solutions for security and scalability
• They step in when complexity exceeds no-code boundaries

External consultants like us at Till Freitag work as sparring partners:

• We help choose the right approach
• We bring experience from 35+ AI projects
• We train teams in Vibe Coding and AI-native development
• We handle the complex parts – custom apps, integrations, agent architectures

The goal: The process owner drives. We ride shotgun.

The Context Engineering Approach

Instead of "AI implementation," we prefer to talk about Context Engineering. This means:

1. Context Mapping: What tacit knowledge lives in this process? Who has it? Where are the edge cases?
2. Context Capture: How do we translate this knowledge into a form an LLM can use? (Prompts, system instructions, knowledge bases, structured data in monday.com)
3. Context Testing: Does the AI solution handle the real edge cases? Does it catch the exceptions?
4. Context Maintenance: How does the context stay current as the process evolves?

This approach is fundamentally different from the classic ML approach ("give me training data and I'll build a model"). It's knowledge-driven, not data-driven.

What This Means for Your Company

If you want to introduce AI in your organization, ask yourself these questions:

1. Who has the context? Not: who can code. Rather: who knows the process inside out? Who makes the decisions? Who knows what "normal" looks like?

2. Do these people have the tools? Do they know Lovable, Make, monday.com AI Workflows? Do they have access? Do they know what's possible?

3. Is there a support structure? Who helps when they get stuck? Who reviews the solutions? Who handles security?

4. Is the culture ready? Can business teams "just build"? Or does everything go through IT? Is the culture one of experimentation or specification?

Conclusion: Context Beats Code

The models will keep getting better. GPT-5, Claude 4, Gemini Ultra – they'll be even more capable than today.

But the bottleneck stays the same: The context has to come from the right people.

No model in the world can know that "approved" means three different things in your company. No model can replace your ops manager's intuition, who recognizes in 2 seconds whether an invoice is right or not.

The solution isn't better AI. The solution is empowering the people with the context to use AI themselves.

AI is not the bottleneck. Context is. And only your people have it.

---

Want to empower your team to build AI solutions themselves? Talk to us about our Vibe Coding workshops and AI enablement programs.