Building Vaton: inside an AI marketing strategy platform

Building an AI marketing strategy platform is not a matter of connecting a model to a text box. The real challenge is making several processes understand a business, research its market, retain the right context, and produce decisions that a person can verify and execute.

That is the product and engineering problem behind Vaton. Our introduction to Vaton explains what the platform does for agencies and small businesses. This article covers the other side from my perspective as a co-founder and hands-on engineer, without exposing proprietary prompts, internal pipelines, or sensitive infrastructure decisions.

The technical picture

• A strategy requires coordinated workflows, not one AI response.
• Every project must keep its context, data, permissions, and history separate.
• Outputs need to be structured, editable, traceable, and verifiable.
• Meaningful time savings require connecting research, strategy, planning, and execution.
• Quality, latency, and cost must be managed task by task.
• Automation needs clear states and configurable approvals.

A marketing strategy is not one AI response

An SEO or content strategy may require understanding the business, identifying audiences, researching competitors, classifying search intent, organizing topics, prioritizing actions, creating outlines, and checking consistency.

Each task uses different information and produces results that affect what follows. The problem therefore looks more like AI workflow orchestration than text generation.

A polished response is not enough. The system needs to provide the right context at each stage, respect dependencies, retain intermediate results, and prevent contradictions. A content recommendation, for example, should not ignore a commercial restriction approved during onboarding.

Building useful, updateable context

A model can write confidently without understanding a company particularly well. That may work in a demo, but it is dangerous in a strategy product: advice can sound professional and still be irrelevant.

Vaton needs to work with several layers of context:

• identity, positioning, and value proposition;
• products, services, and markets;
• audiences, competitors, and goals;
• restrictions and permitted claims;
• the current website and content library;
• previous research and decisions.

That context also changes. A company may launch a service, retire an offer, or start targeting a new segment. The architecture has to accept updates without losing continuity or forcing the user to start again.

The hard part is not storing more text. It is selecting the information relevant to each task and distinguishing facts, hypotheses, recommendations, and approved decisions.

Multi-project means isolation, not just organization

For an agency, managing several clients may look like a folder problem. In an AI application, it means ensuring that every run uses only the authorized context of the active project.

Isolation applies to:

• data and files;
• research and strategies;
• instructions and content;
• integrations and credentials;
• permissions and approvals;
• history and activity records.

When someone switches accounts, the platform must also switch competitors, voice, goals, and available sources. A recommendation that mixes information between clients is both a quality failure and a security risk.

Isolation and access control have to be part of the system model from the beginning—not a visual layer added later.

AI should produce verifiable work

There is a meaningful difference between output that appears correct and work that can be used professionally. Fluent writing may still contain unconfirmed assumptions, irrelevant topics, poor priorities, or claims that are too broad.

Every result should make it possible to answer:

• Which project information was used?
• What evidence or assumption supports this recommendation?
• Which objective does it address?
• How does it relate to the rest of the strategy?
• What should the user do next?
• Does it need review before execution?

Human oversight remains essential for strategic decisions. The point of AI is to reduce repetitive preparation so that people can focus on the work that genuinely needs judgment.

Saving time requires redesigning the whole process

The goal of reducing preparation time by as much as 90% in suitable SEO workflows does not come from faster writing. It comes from shortening a chain of work: collecting information, structuring data, repeating research, classifying opportunities, preparing deliverables, and turning analysis into plans.

Automating one step rarely transforms the operation. Research must feed strategy; strategy must feed planning; and planning must lead into execution.

Technically, that means maintaining states, dependencies, and intermediate results. It also means avoiding unnecessary work: when research is still valid, the system should not repeat the entire process every time someone requests another article.

Actual savings depend on scope, available information, approvals, and project integrations. The aim is to stop users from rebuilding the same context—not to remove professional review.

Editable, structured, reusable outputs

A strategy should not be trapped inside a chat conversation. People need to review it, change it, and use it elsewhere in the project.

One research item may support several decisions. An approved decision may update a plan. A plan may produce multiple briefs or articles. To preserve those relationships, the system has to distinguish among:

• information supplied by the user;
• data found during research;
• generated recommendations;
• approved decisions;
• content ready for use;
• items waiting for review.

That structure makes it possible to correct one element without manually rebuilding everything around it. It also reveals what changed, who approved it, and which deliverables may now be out of date.

Publishing to real websites adds another layer

Generating content is not the same as publishing it. A website may use a CMS, a repository, or a custom content model. Paths, images, templates, metadata, and review flows can vary even between projects built with the same framework.

A publishing integration needs to understand each site’s contract:

• where articles and images live;
• which format and fields are required;
• which naming conventions apply;
• which validation the content must pass;
• who reviews and approves it;
• whether the destination supports drafts or direct publishing.

The engineering challenge is to build flexible adapters without turning every website into a fully custom integration. This article is a useful example: adding it required respecting the project’s bilingual collections, frontmatter, routes, images, and metadata.

Configurable automation and understandable states

Not every account accepts the same level of autonomy. One may allow automatic publishing; another may require an internal review, client approval, or a legal check.

Every important action therefore needs a visible state, such as:

• pending;
• in progress;
• ready for review;
• approved or rejected;
• published;
• failed.

The interface needs to show what is happening, what has finished, and what requires attention. Without that clarity, a long process feels unpredictable even when the infrastructure works as intended.

AI failures are not solved by prompts alone

Prompts matter, but they are one component of the system. Quality also depends on the available data, context selection, task order, constraints, validation, model choice, error recovery, and human review.

A prompt can work well in several tests and then fail when the industry, language, input volume, or clarity of source information changes. The platform has to identify gaps, manage uncertainty, and avoid presenting hypotheses as facts.

That requires evaluation across the workflow—not just inspection of isolated responses.

Quality, speed, and cost pull in different directions

During a prototype, it may be acceptable to run the most capable process every time. In a real product, every task has a cost and latency that affect the experience and the ability to scale.

The most powerful model is not necessary for every operation, while the fastest response may not have enough depth for a strategic decision. Part of the architecture is routing each task to an appropriate process, reusing valid results, and showing progress while longer jobs run.

Optimization does not mean choosing the cheapest possible response. It means achieving the required quality at sustainable latency and cost.

Observability and traceability

In a traditional system, an execution often fails explicitly. In an AI system, it can complete successfully and still produce a poor result. Observability therefore has to cover both execution and output quality.

We need to analyze which context each process received, where a contradiction appeared, what the user changed, which version produced a result, and which actions were approved.

Traceability helps us debug and improve the product. It also builds trust: an agency should be able to connect a recommendation to its client’s information without needing access to the system’s internal machinery.

Security and permissions by design

Once a platform connects to websites, repositories, and client accounts, security is no longer a secondary concern. Vaton needs principles such as least-privilege access, project-level separation, credential protection, action logs, publishing controls, and revocable access.

Automation is only useful when users remain in control of their data and channels. An integration that can publish needs clearer boundaries than one that only prepares a draft.

Working as both co-founder and engineer

My role in Vaton moves between product and architecture. As a co-founder, I have to decide which problem is worth solving and which capability should come first. As an engineer, I have to translate those decisions into reliable systems.

A small interface decision can change the underlying state or permission model. A technically elegant solution can still fail if it forces users to understand concepts they do not need. Building the product means balancing both levels continuously.

The beta develops the system too

The beta is not only for finding visual bugs. It lets us observe how an agency prepares a strategy, presents findings, corrects a deliverable, and approves content.

Early users help identify which tasks take the most time, what data they already have, which outputs they need to edit, which integrations matter, and how much automation feels safe.

For an AI application, technically correct output is not enough. It has to fit the real work of the person who will review and use it.

Frequently asked questions about Vaton’s architecture

Why can’t a marketing strategy be generated with one prompt?

Because it combines dependent tasks—context, research, prioritization, planning, and validation—that require different information and controls.

What is the main technical challenge in a multi-project AI platform?

Keeping every project’s context, data, permissions, and history fully isolated while coordinating reusable workflows.

Can AI errors be solved by writing better prompts?

Not by prompts alone. Quality also depends on data, context selection, task sequencing, validation, observability, and human review.

Why does Vaton keep human approval steps?

Because an output can sound right while relying on bad assumptions or priorities. Approval steps let each team match automation to the risk of the project.

Building Vaton means turning a flexible, variable technology into a tool that feels clear, controllable, and useful. The architecture exists so agencies and businesses can research, decide, and execute with less friction. To see the product experience that infrastructure is meant to support, return to what Vaton is and how it helps its users.