Three Months Until Our Own AI Architecture

The problem was never the model

First: the range. There isn't just one model, but a dozen that should be taken seriously, and they 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 raised the price for an existing model, the cost for the same work jumped from $3 to $5 per million input tokens—and from $15 to $25 per million output tokens. 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 an inexpensive model is used for data retrieval and an expensive one for decision-making. Where a price increase 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 individually 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 up the time saved. At a certain point, uncoordinated use of AI becomes more costly 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 project information and 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 compiled from scratch by hand for every AI task. It was precisely this compilation process 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 server sends its complete endpoint definitions—with half a dozen integrations, the tool description alone takes up a significant portion of the context window before a single question is even 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 handles the task, 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: AI-generated images of design quality, 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 instead of just outputting text. The leaps forward no longer came annually, 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 able to explain them to a client, you have to understand how they work—and turn someone else's models into your own tool. The difference between “we work with AI” and “we know why this output looks the way it does” is what defines expertise. You don’t learn where a model is hallucinating by simply purchasing 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 the Team Day in July 2026, each person spent five minutes showcasing their own setup—ten people, ten ways of working, a shared level of understanding. 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

Vela is the foundation of our new way of working as an agency. The platform brings together our knowledge, our tools, and our processes. This enables our clients to make faster progress on their projects, access our expertise, and take more control themselves.

Our AI platform consists of four components: Vela as the central application, Knowledge as the shared knowledge base within Vela, Mira for orchestration, and Skills for recurring tasks.

1. Vela – the platform

First, we integrated our internal tools one by one—including Asana, Harvest, Confluence, and Pipedrive. Then we took it a step further: We’re building our own tools, tailored to our needs and brought together in a single application. Since the end of July 2026, it’s been called Vela and brings our processes and data together in one place. LibreChat It is connected to Vela via MCP and makes it directly accessible in the chat—for queries, analyses, and working with our agents.

We chose LibreChat in June 2026 because of its security, shared workspaces, and centralized control of API costs. Our platform remains independent of any single model provider. We determine which model handles a task through configuration. If a token price rises, we can switch.

That was problem number one: dependence on individual model providers.

2. Knowledge – Organizing and Making Knowledge Available

Since June 2026, we have been organizing our company, client, and project knowledge into a shared knowledge base. What began as a standalone knowledge service is now part of Vela. Our AI tools access this knowledge via the Vela-MCP. MCP stands for Model Context Protocol—an open standard that connects AI systems with external data and tools.

The structure is intentionally simple:

• Global  – Positioning, Services, Toolset, Team

• Clients  – Target Audiences, Offerings, Proof Points

• Projects  – Context, Objectives, Constraints

• Collections  – Organized document sets within the project

This way, everyone has access to the same knowledge base, and updates need to be made in only one place. Every edit includes a dry-run preview and requires explicit approval. This is inconvenient—and exactly as intended: A knowledge repository that agents fill up unchecked becomes useless after three weeks.

We have outlined the principle behind this:

"Customer and project knowledge belongs in the company's shared memory, not in the prompts of individual agents."

That was problem number three: the lack of context.

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 standard assistant in Vela. She coordinates the work of the specialized agents: she understands the request, determines what knowledge and tools are needed, and assigns the tasks. She then reviews the responses and compiles them into a coherent answer.

The Specialists They take on clearly defined tasks and access the systems needed for those tasks—such as Vela, DatoCMS, GitHub, or Google Workspace. When a question involves multiple systems, a Router in between, who in turn delegates tasks: for website research, for financial control, for publication. Each specialist works in isolation and returns only its result—not the steps it took to get there.

This keeps the context manageable: Each agent receives the information and tools it needs to perform its task. We have been using this orchestrator architecture since mid-July 2026.

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 top prices only for the part that requires top quality.

Those were problems one and three combined: vendor lock-in and a lack of context.

4. Skills: Common Standards for Recurring Tasks

An agent that has to improvise from scratch every time is too expensive and too slow. That is why our procedural knowledge lies in Skills – versioned work instructions for recurring tasks. They are the solution to the problem of ten people solving the same task ten different ways.

Our skills are managed centrally and further developed as a team. When someone improves a process, the entire company benefits. We synchronize our skills with the AI tools we use so that everyone works from the same foundation—regardless of which tool they use for a given task.

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 Skills includes Lighthouse metrics for mobile and desktop devices per page, along with prioritized recommendations. The DatoCMS Knowledge Pack Skill Scans a CMS project in read-only mode and stores 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: the team's fragmented work processes.

AI is a super booster for Gridonic

Vela brings our tools and our knowledge together. The Vela-MCP makes both accessible to our agents. Mira compiles an answer from multiple sources. Skills turn a good solution into a repeatable one.

What works. Since July 2026, we’ve been conducting website audits on a regular basis and comparing the results over time. During one of these audits, a schema issue that had already been resolved reappeared. Thanks to the saved results, we immediately recognized that this was a recurrence, not a new issue. The CMS Knowledge Package, on the other hand, 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: Model changes are now simply a matter of reconfiguring our system. No project has ever had to wait because of this. At times, we’ve replaced Claude with DeepSeek or Kimi. For many of our tasks, the results were 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. What’s more, agents hallucinate most convincingly when information is lacking. 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 else is on our minds. Any organization that employs agents with write access to customer systems needs clear rules. To that end, we have established a written framework that we are continually refining. Our principles: keep critical actions controlled and traceable; do not invent missing information; and verify sources rather than make assumptions.

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 actual use.

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’s 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 remains our challenge. And we're getting better and better at it—with AI as our superbooster!