The problem was never the model
First: the width. There isn't that It’s not just one model, but a dozen serious ones, and they each excel at different things. One writes better code, one reads longer documents, one generates more useful images, and one is simply ten times cheaper for simple queries. Subscribing to all of them is absurd—you’re paying seven times for capacity you only need once. Relying on just one is risky.
And it’s actually quite risky. When one of the providers changed its standard model, the token price for the same work rose from $3 to $5 per million input tokens—and the fees from 15 to 25. Overnight, via a product announcement. Anyone who bases their workflow on a single provider’s chat window makes their business model dependent on that provider’s price list. And price lists are the only thing about this technology that changes even faster than the models themselves.
This led to a requirement for the Gridonic AI platform: We build in an LLM-agnostic way. A system in which the model is a configuration rather than a fundamental decision. Where you use an inexpensive model for data queries and an expensive one for decision-making. Where a price jump means a minor adjustment rather than a time-consuming migration.
Second: fragmentation. On Team Day, ten people demonstrated ten different ways of working. From a learning perspective, that was great; from an operational standpoint, it’s inefficient and ultimately costly.
That’s because individual productivity doesn’t automatically add up to team productivity. When each person works with their own model, their own prompts, and their own approach, the results are good on their own but useless when combined. An audit cannot be compared to the one from the previous month because the approach was different. Two people end up duplicating the same preparatory work because neither is aware of what the other is doing. Knowledge from a project remains trapped in that project’s chat history and is lost when the project ends.
The time spent on post-processing eats into the time saved. At a certain point, uncoordinated use of AI becomes more time-consuming than not using it at all—because then you end up with both: the cost of the tools and the cost of coordination.
Third: the context. Both issues stem from the same shortcoming. Every conversation started from scratch. Anyone who wanted to write a proposal first had to explain to the model who the client was, what we’d done for them, and what our positioning was. Anyone who needed an audit would copy login credentials and project notes into the chat window. The agency’s knowledge was stored in people’s heads, in Asana, in Drive, in DatoCMS—and had to be manually gathered anew for every AI task. It was precisely this process of gathering information that each person handled differently.
By the way, adding more integrations didn't help. Our first instinct was to activate all available MCP servers at once. That backfired: Each active MCP sends its complete endpoint definitions—with half a dozen integrations, the tool description alone took up a significant portion of the context window before a single question had even been asked.
That defined the goal, and it wasn't about "better models" or more CPU power. It was about Orchestration : a layer that knows which knowledge applies to which task, which model it executes, and in what sequence—so that each person no longer has to make these three decisions anew and differently every time.
What does this mean for us as a digital agency?
In May 2026, the agenda for our monthly “Gridonic Engine” meeting included an item that would have sounded like science fiction just a year earlier: design-quality generative image generation, along with process automation and caching strategies, because we were hitting API limits.
That was the moment when it became clear just how far the models had come. They were writing production-ready code instead of snippets. They were reading entire codebases instead of commenting on individual functions. They were generating images that passed design reviews. And they began using tools on their own, rather than just outputting text. The leaps forward were no longer annual, but quarterly—and today, even monthly.
For a digital agency, this isn't just a question of tools. It's a matter of survival.
Project management, concept development, workshop preparation, and front-end work are now heavily AI-supported at our company, using agents and skills. It became clear to us that: It's not enough just to use these systems. If you want to be accountable for them to a client, you have to understand how they work—and to do that, you have to run them yourself. The difference between “we work with AI” and “we know why this output looks the way it does” is what determines competence. You don’t learn where a model is hallucinating just by buying a subscription. You learn it by putting together the context yourself, bearing the costs yourself, and cleaning up the mistakes yourself.
So we really dove in. At Team Day in July 2026, each person spent five minutes showing their own setup—ten people, ten ways of working, a shared understanding of where we stood. We built our own platform, ran our own knowledge server, and tested and discarded agent architectures. Users became operators. And operators became specialists—not because we set out to do so, but because you only learn it by actually doing it.
Our AI Platform
As part of our new agency model, we base everything on our AI platform, "Vela." Vela offers a set of agents and skills that help our clients make faster progress on their projects, gain access to more knowledge, and work much more independently.
We built "Mira" in four layers—one for each problem.
1. Vela – The Platform
We initially integrated our many internal tools one by one (e.g., Asana, Harvest, Confluence). However, we’ve since phased out most of them and rebuilt them from scratch. Since the end of July 2026, it has been called Vela . It is the central application with a shared data pool. LibreChat It also serves as a chat interface for quick experimentation.
Vela is not tied to any LLM provider. The decision to use LibreChat instead of direct provider access was made in June 2026 for three reasons—security, shared workspaces, and centralized control of API costs. Which model executes a task is therefore a matter of configuration, not architecture. If a token price rises, the system is switched over, not migrated.
That was problem number one.
2. Gridonic Knowledge – a central warehouse
Our project has been running since June 2026. Knowledge MCP Server . MCP stands for Model Context Protocol—an open standard that allows AI systems to access external data sources. Instead of copying facts into prompts, the agents retrieve the context from where it is maintained as the authoritative source.
The structure is intentionally simple:
-
Global — Positioning, Services, Toolset, Team
-
Clients — Target Audiences, Offering, Proof Points
-
Projects — Context, Goals, Constraints, ope
-
Collections — Organized document sets in the project
From an editorial standpoint, the Git-backed system runs through the repository gridonic/knowledge . Every write operation includes a dry-run preview and requires explicit approval. This is inconvenient, but that’s exactly the point: A knowledge repository that agents fill up unchecked becomes useless after three weeks.
We have outlined the principle behind this:
"Treat client and project knowledge as shared organizational memory, not as agent-specific prompt text."
That was problem number three—and the prerequisite for Shift 3 to work at all.
3. Mira and Her Specialists—The Orchestration
This is the real crux of the matter, and the diagram illustrates it from top to bottom.
A request first encounters Mira , the default assistant in Vela. Mira does not have any data sources of her own. Her task is to make judgments: understand the question, decide which sources are needed, delegate the task, review the responses, and use them to construct a coherent answer.
Below that are the Specialists — one each per system: canonical company knowledge, Asana, DatoCMS, GitHub, Pipedrive, Google Workspace. When a question involves multiple systems, there is a Router in between, who in turn delegates tasks: for website research, for financial control, for publication. Each specialist works in in isolation and returns only its result—not the process by which it arrived at that result.
That's exactly what solves the context window problem. Our first instinct was to activate all MCP servers at once; that backfired because the tool descriptions alone took up a significant portion of the window before a single question had even been asked. In the Orchestrator architecture, which has been in use since mid-July 2026, each agent sees only what it needs.
And that's what makes vendor independence so valuable: data retrieval and filtering are handled by affordable, fast models, while orchestration and decision-making are handled by a high-end model. You pay premium prices only for the part that requires top-notch quality.
Those were problems one and three combined.
4. Skills: Processes that run the same way every time
An agent that improvises anew every time is too expensive and too slow. That is why our process expertise lies in Skills — versioned work instructions for recurring tasks. They’re the solution to the problem of seven people solving the same task seven different ways.
The development process is structured: A new skill is created in LibreChat, tested there, and only then moved to the repository. gridonic/skills . It is visible to the entire team only if you have an admin role. Quick experimentation, controlled rollout.
The Skill Website Audit (SEO/GEO/AEO) analyzes search engine, generative, and answer engine signals, assigns scores, and tracks regressions across runs. The Performance Audit Skill is a Lighthouse metrics for mobile/desktop per page, with prioritized recommendations. The DatoCMS Knowledge Pack Skills can set up a CMS project as read-only and store the schema, roles, plugins, and inventory as a reusable knowledge package.
A skill is therefore more than just a saved prompt: It determines which sources are queried, in what order, and to what quality standard—and ensures that the results remain comparable over months.
That was problem number two.
AI is a super booster for Gridonic
Vela frees us from dependence on any single provider. Gridonic Knowledge makes knowledge reusable. Mira combines information from many sources to provide an answer. Skills turn a good solution into a repeatable one.
What works. The website audit has been running since July 2026 in eight cycles—not as a one-time report, but as a time series. That’s exactly where its value lies: In one cycle, a schema issue that had already been fixed resurfaced. Without the historical data and without following the same procedure, no one would have noticed; it would have been interpreted as a new issue rather than a regression. The CMS knowledge package, in turn, saves us from having to perform a full project scan with every new session and, incidentally, revealed a backlog of maintenance tasks that we had overlooked for years—over a thousand images without alt text and orphaned environments.
Our vendor independence has also paid off, albeit in an unspectacular way: For us, model changes are now simply a matter of adjusting the configuration. No project has ever had to wait because of this. On some days, we’ve worked with Deepseek or Kimi instead of Claude, and the results are often comparable in quality.
What we've learned. Context is more valuable than intelligence. Selective MCP activation and subagents with isolated context have yielded better results than any model upgrade. Furthermore, agents hallucinate most convincingly when they are absent. In September 2026, an agent “remembered” a document that had never been uploaded and continued to work with it consistently. Not wrong in the details—wrong at its core, yet completely confident in its tone. This led to a strict rule: A failed retrieval is never proof of absence. When a source fails to deliver, this is acknowledged rather than glossed over.
What's open. The biggest challenge is governance. We have principles—keep critical actions controlled and verifiable; don’t invent login credentials or contract details; and consult a tool rather than guess. What we don’t have is a formal AI policy: no approved document specifying which customer data is allowed in which systems, how providers are assessed for compliance with data protection laws, or how login credentials are handled in agent operations. Security guidelines are scattered across agents and chat histories, and there have been incidents. Anyone operating agents with write access to customer systems needs a written framework for this. We have now created this framework and are continuing to improve this guidance—the Roolbook.
And what that did to us. It all started with the assumption that these systems must not only be used, but also understood. Today we know what that costs—and what it delivers. We know where a model is reliable and where it is reliably wrong. We know the cost of context. We know which tasks can be automated and which only appear to be. None of this is in the product documentation. You learn it through hands-on experience.
That’s why our AI setup isn’t a product, but rather an operational state—one that will continue to evolve. The interesting question is no longer whether an agency uses AI. It is whether an agency has organized its own knowledge in such a way that a machine can work with it—and whether it still retains the ability to judge which of the generated options are actually viable.
We've come a long way with the first one. The second one is still our challenge, and we're getting better and better at it—Superbooster!