Creating images with AI is fun. But once you want to generate a family of images, you invest more time into managing your prompt than into having fun.

With Images, you can use my prompt templates and customize them to your needs or create your own templates and distribute them:

Open the App

Since I am not rich (but I assume you are :D), you will have to bring your own OpenAI API Key (you can get it here).

Entering your key into my site will not allow me to access it, as it is encrypted and decrypted by your browser. Feel free to investigate in my "Homepage" repository.

Taste requires the creator of something to know of other people's expectations without asking. What is a valuable information? What is visually pleasing? What matters in daily life? And most of all: How can we push boundaries without annoying others?

After all, taste is a protocol: It defines the boundaries of what is currently seen as valuable and aesthetic applied to daily life and to everything that can be describes as a product.

AIs do not have taste. They simulate taste by having seen all approaches to all challenges product people ever had, knowing all the best practices. Yet as soon as you push the boundary to the unseen or very specific, AIs fail; even worse, they drown you in options and overcorrect if not instructed well.

AIs can come up with valid options, but they are always annoyingly mid. I don't see this to change any time soon. So we continue to have to provide the taste. Pick the right options, push for more options, tell it to not do "the right thing".

So AI has changed nothing with regards to taste, except that ok-ish taste (the so called "AI Slop") is the new baseline. Actually, the value of good taste has never changed much, even when a taste itself has changed a lot accross centuries.

You can not buy taste. My grandmother

Tba.

I work with a family of local Agents that streamline what I do.

Yes, they multiply my productivity. These Agents follow a set of simple principles that reach these goals:

Let us assume you have not yet built your own Agents (or are unhappy with them). Let us further assume you are a non-technical person. Then I think there are good reasons to use the method as your next step:

• Simplicity: Each Agent is a folder on your computer that contains your domain expertise as single files. Each file is a self-contained program made of natural language, arranged in sub-folders that define its purpose and application.

• Portability: We don't know what the future brings, but we do know that we want to participate. So any effort you put in must result in your domain expertise being consolidated in a standardized, ready-to-transfer format.

• Sovereignty: I suppose you value technical independence. These Agents work with any Model, Provider, and Harness, including local Open Source. They even don't require the latest and greatest Models: Small and fast works best.

• Locality: With the Agents being a mere filesystem on your computer, you and you alone have control over what it knows and does. To provide your Agents to others, there are options (but the basic variant is not collaborative).

• Extensibility: Once you implemented one Agent, you can apply the same method to other use cases. The filesystem-approach allows you to link folders and files, so nothing needs to be written twice.

If these benefits resonate with you, I invite you to set up your Agent(s) by following my tutorial, which will take an afternoon:

Tutorial: Build your Local Agent

It explains the method's conventions, walks you through all folders and files, and provides you with all instructions that implement the core behavior. Once set up, you will understand the method, your Agent, and how to refine it.

But before you start, please note these three restrictions:

I hope my method helps you enter the space of agentic AI or to refine your approach!

Since the term was coined, "Prompt Design" has changed a lot, as LLMs get better while harnesses provide tools and structure. What has not changed is that you want your AI to communicate in certain ways and depend on your input before burning your tokens.

I have documented the text snippets I regularly use, since ~2 years. I call those "Protocols".

Since Protocols are solely about behavior, they can be applied to any subject, from code planning to compiling grandmas recipes.

Two Protocols stand out in my daily usage:

• The Ask Protocol makes the AI ask you questions until it knows exactly what you expect. This turns hallucinations into questions and prevents any surprises caused by gaps in your request. Actually, once you rely on that, you will keep your request free from details – if details were needed, you know the AI will ask.

• The Next Protocol makes the AI turn anything into a step by step walkthrough. This prevents it from "running away", leaving you with an (eventually great) solution but no clue why and how that works. Furthermore, it allows you to intervene at any time, keeping you in control.

Both Protocols give you the most convenient ways to steer the conversation. To make things even more convenient, there is a great way to integrate your protocols in any textbox on your computer.

Open the Prompts page

Enjoy!

AI tools promise acceleration. Many providers have responded quickly. Some have responded loudly. What I observe, however, is not simply the rise of AI. We observe an industry at an inflection point.

On one side are those who adopt automation deliberately — keeping the human in the loop, yet often only formally. On the other side are those who either resist automation altogether or apply it superficially, hoping that “adding AI” will create value by default.

AI systems generate language through statistical prediction — which means the quality of their output depends on the context they are given. So the real question is not whether to use them. It is: How do we embed AI so that actual human expertise scales?

The Structural Challenge

Reporting today is data-intensive by design. ESG, climate, supply chain, and financial datasets are increasingly granular, interconnected, and auditable. At the same time, the final output must remain clear, coherent, and strategically aligned.

Large Language Models (LLMs) can help transform data into text. But they require context – and context is expensive. Common approaches attempt to solve this in three ways:

• Context bloat: Provide as much information as possible and hope the model “figures it out.”

• Retrieval-based systems: Dynamically search for relevant pieces of information and feed them into the model (RAG), which is harder than assumed as datapoints constantly change.

• Technical prompt engineering: Build custom, programmed pipelines per use case.

Each of these can work in isolation. None of them scale sustainably. The structural problem is this: There is no deterministic layer that embeds domain expertise into the transition between data and AI.

Without such a layer, automation either becomes unpredictable — or dependent on constant technical intervention.

The Missing Layer: Structured Integration of Expertise

Between raw data and AI inference, there must be a layer that:

• selects relevant information,

• applies domain logic,

• expresses knowledge in controlled natural language, and

• remains readable and editable by (non-technical) experts.

In other words: human judgment must become part of the infrastructure. Not as an afterthought or buried in engineering code. But structured, explicit, and intelligible.

Human judgment must not be an external input to the system. It must be encoded into it. And that is difficult — unless the structure itself is designed for experts.

You Need a Transformation Engine

To operationalize this principle, I developed PDL — Prompt Data Language.

PDL is a format for writing highly structured natural text. It follows the widely adopted Markdown standard, but extends it with a small but expressive set of logical elements: retrieving values, defining conditions, iterating over data.

The input is designed for domain experts; the output is designed for humans and LLMs alike.

With PDL, structured datasets and domain logic are fused into deterministic yet elegant natural language before any AI model is involved. What the model receives is not raw data, but curated, intentional context.

This makes the human contribution tangible and maintainable. It becomes part of the system — not an informal comment in a workflow, not a technical workaround, but an explicit layer.

A Simple Example

Imagine a structured dataset of products and their emissions. A PDL template could look like this: What this achieves is deceptively simple.

It translates structured data into consistent natural language. It embeds a clear threshold. It makes the decision logic explicit. It produces deterministic output — every time. It can be evolved easily and constantly.

The logic is visible. The reasoning is traceable. Any domain expert can read and refine this logic. Then the AI systems can build on it. The result is structured, auditable, and scalable.

How This Works in Practice

In our automation work, this layer typically sits right before AI inference happens.

Consider a recurring scenario: A company has not yet provided all datapoints required for a report. Each week, a checklist is needed — along with a management summary.

Instead of manually drafting this from scratch or feeding entire databases into an LLM, a PDL template extracts missing datapoints, applies domain logic and generates a structured briefing. This briefing is then used by an AI system to produce a coherent management summary.

The result is:

• Deterministic data selection.

• Controlled natural language.

• A focused AI prompt.

• A faster and more reliable output.

Importantly, the quality of the outcome depends on the quality of the underlying data. Structured environments like the VERSO Hubs — where ESG, climate, and supply chain data are curated systematically — provide the ideal foundation for this approach.

The more disciplined the data collection, the more powerful this abstraction layer becomes. Data does not merely serve compliance. It becomes a strategic asset for truly intelligent automation.

And because this layer remains human-readable, consultants and domain experts can continuously refine the logic and add depth without requiring engineering resources for every iteration.

What This Means for You

Infrastructure only matters if it creates tangible value.

If you work with us in services, it means both your and our expertise become scalable. Domain knowledge is no longer confined to individual documents or projects. It becomes part of a reusable, evolving structure.

If you are using our Hubs, structured automation increases the leverage of your data. The more consistently your information is curated, and the more human intelligance it can be merged with, the more precisely it can be transformed into actionable outputs.

If you are considering working with us, it means you are not investing in short-term AI experimentation. You are building a foundation that integrates automation responsibly — with human judgment embedded from the beginning.

Across all scenarios, the principle remains the same: AI becomes more reliable when expertise is structured — and only then can it become part of your everyday workflow.

Designing the Future of Reporting

The future of reporting will not be defined by who “uses AI.” It will be defined by who designs the systems around it. Automation without structure leads to noise. Manual processes without automation lead to inefficiency. The sustainable path lies in structured collaboration between humans and machines.

PDL is one building block in that architecture: Structured collaboration between humans and machines — transparent, traceable, and accountable.

The industry continues to evolve. We intend to shape that evolution in a way that keeps reporting precise, actionable, and accountable. We are committed to building infrastructure that strengthens quality rather than replacing judgment.

If you are curious, explore our open-source PDL Repository or interact with it in the PDL Playground*. It is a small but tangible glimpse into how we think about the future of reporting.

Tba.

Backlog

Tba.

My homepage is a collation of Markdown files published as an app.

That is also what I like about working on it. I can write a paragraph, give a section a heading, or add a link in a text file. A few small extensions let that document become something richer: a presentation, an interactive page, or an explanation that adapts to the person reading it.

For example, a passage can look like this:

Welcome to my Homepage.

Here you will find my writing, projects, and experiments.

[interest:AI]
    You might enjoy how I work with AI agents to build this site.
[/interest:AI]
[!interest:AI]
    Start with a topic that interests you and explore from there.
[/!interest:AI]

The two conditions select different passages according to an interest in the reader's preferences. The surrounding document stays the same. I can read the source, understand the intention, and change the wording without reconstructing a component tree in my head.

This is the idea I keep coming back to: plain Markdown and a lean personalization syntax can support complex user experiences that remain document-style experiences. There is still a text to read, a structure to follow, and a link to open. The application quietly supplies the behavior around them.

AI fits naturally into that arrangement. Agents can work with the same files I use, and readers can open Markdown and Prompt versions of the published content. Behind the scenes, two Artificial Colleagues help me develop the system and maintain its content.

A document with more possibilities

The source should stay pleasant to write, even when the result becomes more capable.

I like Markdown as a working format. It has enough structure to organize an idea, and little ceremony between having that idea and writing it down. A page can begin as a few headings and paragraphs and acquire more detail as I work on it.

The Homepage extends that familiar vocabulary. A link can become a button. A blockquote can become a note. A short listing can collect posts or presentations. A section can fold away an explanation that some readers want and others can skip.

The content is authored in Markdown.

> [Tip]
> Open the Markdown link in the footer to take a closer look.

[Explore the presentations(primary-button)](/presentations)

Here, [Tip] selects the note treatment and primary-button selects the link presentation. The words remain close to the behavior they describe. I can make the intent explicit in a line of source and let the renderer take care of the details.

Personalization follows the same principle. Conditions wrap the passage they affect. They can surround a sentence, a heading, a list item, or a larger section. That keeps the editorial decision visible: this is the explanation I want to offer to this reader, in this part of the document.

There is an interesting difference between making a document responsive and making it personal. A narrower screen may need a shorter passage or a different composition. A reader who has expressed an interest may appreciate a more specific introduction. Both can be authored close to the content, while the implementation handles their different sources of context.

This is particularly appealing for a personal homepage. My visitors may be interested in my professional work, an experiment, a presentation, or the AI behind the site. A document can give those interests room without making everyone follow the same tour.

Where the conditions are evaluated

The syntax is compact; the runtime distinguishes the kinds of context behind it.

Cohort and preference conditions are evaluated on the server using the context available for the request. Width conditions work differently: the server can send the relevant alternatives together, and CSS selects the matching viewport variant before first paint and on resize.

This is personalization of presentation. Access control needs its own implementation. In particular, a viewport variant that is visually hidden may still be present in the response, and a public Markdown representation needs its own publication review.

A small language for rich content

A few well-chosen extensions can carry a surprising amount of expression.

The same approach extends beyond prose. A document can include media, listings, and configured Elements. The important part for me is that these remain authoring choices I can see in the source.

An app embed, for instance, uses a fenced block with a small configuration:

```element embed
app: images
mode: inline
```

The element prefix tells the generator to interpret the block as configuration. A regular code fence remains a code example. The configured Element then uses behavior provided by the application.

I call these Markdown extensions. Their usefulness comes from how consistently they connect a readable instruction to an existing capability. An author can choose a treatment or configure an Element; developing a new capability means extending the generator and renderer as well.

The blog format itself offers a good example of this range. Headings can organize expandable sections. Code blocks can start open or closed, carry useful labels, and offer wrapping controls. Images can use different presentation sizes. Lists can express a collection of content or an interactive structure.

I want to use that flexibility with some restraint. The main explanation should remain easy to follow. Details can be available exactly where they become useful. A reader should be able to stay with the story, inspect a small example, or open a deeper explanation according to their interest.

There is a maintenance cost to every new piece of syntax. It needs a clear meaning, examples, and predictable behavior. The payoff is strongest when one extension is useful in several places and the authoring experience stays coherent.

For agents, those conventions serve another purpose. A request such as “add a note here” or “show this passage to readers interested in AI” has a compact representation in the file. The surrounding prose, links, and headings provide context for the change.

A compiler does the translation

Readable source becomes structured data before the application serves it.

The Homepage has a Backend, although its main job happens during generation. A Node.js program reads the authored content and prepares the data that the React application will use. The same generator can run locally and during the remote build.

The core content object is a Content.md file with YAML frontmatter and a Markdown body. The frontmatter supplies metadata such as title, summary, and publication status. The body carries the text and the structures that become rendered Elements.

Generation connects those pieces to the larger application. It resolves content and navigation, prepares registries, and emits importable TypeScript data. It also produces the public Markdown and Prompt representations that I will return to later.

That translation is a useful place to be explicit. Authored source can be convenient for writing, while the runtime receives a normalized representation. A page loader can look up prepared content and pass it to a shared rendering surface.

It also makes a change easier to investigate. I can look at the source, the generated data, and the rendered result as separate stages. If a heading is missing, a link resolves unexpectedly, or an Element receives the wrong configuration, I have a path to follow.

The generator reports problems close to the content that caused them. It stages its output before replacing managed directories, reducing the chance of leaving a half-written generation behind. Generated artifacts remain outputs: lasting changes belong in their source or in the transformation that produces them.

What the generator produces

The application imports more than page bodies.

The outputs include content modules, route and navigation registries, theme data, app registration, public source files, and prepared assets. TypeScript gives the frontend a visible representation of the generated contract. Validation and type checking then check different parts of the path from authored data to application code.

The usefulness of that arrangement depends on the schemas and consumers being well maintained. Having the transformation in code makes those decisions available for inspection and improvement.

Remix gave the application its shape

Framework conventions make it easier to describe a change and find where it belongs.

I got to know Remix at Statista through Markus Wolf and other great colleagues. That is part of the history of this Homepage: the framework became one of the foundations I wanted to work with myself.

The application stack now uses React Router 7 in Framework Mode, continuing the Remix v2 lineage. The Remix documentation points to React Router for the framework's continuing features. For me, the attraction is the application model: routes, data loading, rendering, and server behavior have established places to live.

I find that structure particularly friendly to AI-assisted programming. When I describe a change, there is a recognizable vocabulary for investigating it. A route module loads data. A shared surface renders it. A server helper prepares request-specific behavior. The agent can trace those responsibilities through the code.

In this Homepage, the ordinary page route is a small example. It resolves the path, finds the generated content, prepares a route payload, and passes that payload to ViewSurface. Presentation routes add covers, agendas, chapters, and slides around the same general content system.

The route in four steps

A small module connects the request to the shared presentation layer.

Request path
  → generated content lookup
  → server-side preparation of the route payload
  → shared ViewSurface component

React Router's route modules provide conventions for data loading, actions, metadata, error handling, and rendering. Those conventions give the project an architectural vocabulary that is useful to both a human developer and an agent.

Vite makes the development loop feel immediate. I can inspect a change in the browser, adjust it, and inspect it again. Its tooling supports hot updates and React Fast Refresh; the Homepage also watches generated content and reloads when that output changes. Vite 6 features

The project runs type checking separately, along with tests and a build. That distinction matters because Vite transforms TypeScript without performing the full typecheck. The feedback loop benefits from both a quick visual result and checks that examine other kinds of mistakes.

Cloudflare completes the stack with a concrete production runtime. A Worker entry receives the request, supplies server environment context, and delegates to React Router's request handler. Client assets accompany the server application.

This combination suits the way I work with AI: clear conventions, inspectable artifacts, and a short path from a proposed change to something I can examine. That is my experience of the stack. The point I can demonstrate here is how the responsibilities fit together.

Two Colleagues keep the work moving

The system and its content each have a role dedicated to their continuing development.

I work with two Artificial Colleagues: Homepage Builder for the system and Homepage Manager for its content. They work on my behalf, with me providing direction and making the decisions about what I want to build and publish.

That arrangement makes the Homepage a continuing collaboration. A content task may involve shaping an explanation, organizing a page, or configuring an existing Element. A system task may involve changing the behavior that makes those authoring options possible.

The two roles sit within my broader Platform. Their working context includes instructions, knowledge, procedures, requirements, and the artifacts produced by earlier work. A new conversation can begin from those materials and the task at hand.

Andrej Karpathy's post about LLM Knowledge Bases was a conceptual inspiration for this approach. His original X post and accompanying LLM Wiki idea file describe an agent maintaining a persistent, linked collection of Markdown under human direction. I developed that inspiration into the Platform and the specialized Colleagues I use here.

What interests me is the accumulation. A useful explanation, a clarified requirement, or a working procedure can become material for the next task. The context has a place to live, and I can inspect it alongside the work it helps produce.

The division between system and content gives a task somewhere to start. If I want a new passage or a different arrangement using existing features, that is editorial work. If I want a capability the authoring language cannot yet express, that becomes a requirement for the system.

I still need to judge the result. I decide whether an explanation sounds like me, whether a feature is worth its complexity, and whether a change is ready to publish. The Platform makes these responsibilities explicit in its working procedures and authority boundaries.

Persistent context needs care of its own. Instructions can become stale and requirements can drift away from code. I want the Colleagues' working material to remain as understandable as the documents they help create.

The reader can bring an agent too

A page can continue into a conversation with the reader's own AI.

AI is involved in creating the Homepage, and I want it to be useful when someone reads it as well. That is the purpose of the Markdown and Prompt links in the footer.

The Markdown link opens a prepared representation of the page's content. The Prompt link adds context and directions through a template. Someone can take that material into their own AI tool and continue exploring the subject there.

The foundation is already implemented: source generation, Prompt templates, and the footer links. The broader interaction is still developing. I am interested in how a reader discovers the option, what context makes the handoff useful, and how the conversation can remain connected to the page.

One source can consequently support several ways of engaging with an idea. A reader can follow the visual page, explore its links, or bring its text into a conversation. I like that the content remains available for whatever kind of attention the reader wants to give it.

How a Prompt gets its context

A template combines reusable wording with information from the page.

This page is titled "<Title>".
Its summary is: <Summary>

Canonical page: <UrlWeb>
Markdown source: <UrlMarkdown>

Use this content as the basis for our discussion:

"""
<Markdown>
"""

The generator replaces the placeholders with metadata, links, and the prepared Markdown body. Reusable profiles provide templates for different content kinds. An individual content item can use its own Prompt.md when it needs custom wording, following the profile-selection rules.

The public Markdown is prepared separately from the private authoring source. Comments are removed outside code fences, hidden sections follow the content settings, and root-relative links become public links. A small metadata header identifies the content and its source.

Those templates are another piece of editorial work. A good one can explain the purpose of a presentation or give context for an app. I want to develop that part through use: observe which explanations help, improve the templates, and make the handoff easier to discover.

A delivery pipeline I can trust

A local change should become a reproducible build.

I have liked Cloudflare for nearly a decade. The Homepage gives me a practical reason to keep liking it: the application, static assets, and managed media fit into a delivery environment I enjoy using.

The current pipeline connects a GitHub runtime repository to Cloudflare Workers Builds. Before a change reaches that remote build, the local deployment procedure processes media, runs checks, and assembles a temporary deployment package. It reproduces the Cloudflare build against that package before pushing it.

One detail matters when apps enter the picture. Locally, the Homepage can work from a link to app distributions maintained elsewhere. The deployment package materializes the publishable distribution files, giving the remote build concrete inputs it can use independently of my machine.

Wrangler handles Cloudflare tooling, including authentication checks and uploading selected server secrets separately from the package. Cloudflare Workers Builds performs the connected repository build and deployment; Wrangler supplies the command-line interface.

GitHub Actions is a documented alternative runner for the build procedure. The current setup uses Workers Builds, and keeping the build sequence explicit leaves room to run it elsewhere later. Cloudflare's GitHub Actions integration

What I value is being able to follow the change all the way through. There is an authored input, an implementation, a set of checks, a package, and a remote build. When something goes wrong, those stages give the investigation a useful shape.

Keeping it understandable

The nicest feature is being able to keep working on it.

For me, these choices belong together. Markdown makes content approachable. A small set of extensions adds expression. Generation connects authoring to the runtime. React Router, Vite, and Cloudflare provide a recognizable application and delivery structure. The two Colleagues help me continue the work with context that can persist between tasks.

The design also gives me a useful question to ask of a new feature: can I explain what this adds to the document and how an author would use it? If the explanation becomes complicated, the authoring model probably needs more thought.

There will always be implementation detail underneath. A short marker can stand for a substantial amount of code. What I want is a coherent relationship between the two: a compact instruction in the source, a documented meaning, and behavior I can examine in the result.

The reader-facing AI integration is the part I especially want to develop further. Markdown and Prompt links provide a starting point. Making them feel natural and useful belongs to the same design problem as the rest of the Homepage: helping someone follow an idea without making them learn the machinery first.

I want to keep adding things I care about—writing, presentations, tools, experiments—and keep enjoying the process of putting them together. A bunch of Markdown gives me a surprisingly good place to start.

For the practical details, start with the documentation.

Acknowledgments

Good tools arrive through good ideas and good people.

Andrej Karpathy's LLM Wiki work inspired the persistent knowledge and instruction approach behind my Platform. I learned about Remix at Statista from Markus Wolf and other great colleagues. Cloudflare has been a long-standing favorite, and its tools help make this particular project practical. I am grateful to the people building and maintaining these foundations.

One of my favorite projects is MTAM (MarTech Agents Manager) developed with Maik Sicks for Statista.

MTAM is a tiny (cachable 41kb) javascript library, initialized once per page load, that loads and orchestrates javascript snippets from Martech systems such as CDPs, Analytics, or CRM.

I liked this project because it takes a very basic Marketing problem by the horns and creates transparency.

MTAM solves many practical challenges at once:

• Development

  • Each agent is low-code javascript, discussable with non-tech persons.

  • All agents "speak the same language" and behave comparably.

  • A shared KV-store and common methods allow for simplicity.

• Product

  • Decisions can be made based on data from the Marketing systems.

  • Integrate any tracking and recording based on CDP data.

  • Conduct user research based on cohorts and events.

• Marketers

  • Agents are as-understandable-as-possible due to highly readable code.

  • Adding an url-parameter makes any pageload tell a story in the console.

  • The flow of data becomes easy to investigate.

• Compliance

  • Data protection officers can investigate.

  • Concerned users can see the data flow.

  • Authorities can see archived data flows.

Try it out

1. Click this button:

Development Mode

2. Then open the Dev Tools (cmd + opt + j) console.

3. Then reload (cmd + r).

Keep the console open to see all that is happening in Marketing.

Use it yourself

Feel free to use MTAM yourself!

Open Github Repository

The license is MIT – free to use, even commercially, without any liability on my end.

Getting started

Read the ...

Technical Documentation

... or give these prompts to your AI:

Closing notes

Read more in the Technical Documentation.

If you have questions or need support, let me know!