DEV Community: Kacper Włodarczyk

Build a small LLM wiki in an AgenticOS project

Kacper Włodarczyk — Thu, 05 Nov 2026 09:30:00 +0000

Build a small LLM wiki in an AgenticOS project

A team accumulates project briefs, meeting notes and product decisions. Answering the same question repeatedly is useful, but it leaves another opportunity: keep a readable set of notes that connects the sources and improves as new material arrives.

An LLM wiki is a practical scenario for AgenticOS Projects. The project holds shared files and instructions across chats, and an agent can work on those files. The useful output is a knowledge artifact the next colleague can open and maintain. Drafted with AI assistance.

The walkthrough uses fictional company documents. The screenshots come from a real wiki I built from Hacker News stories on a test instance. I build AgenticOS at Vstorm.

Choose a topic a teammate would ask about

Start with a synthetic product launch. Prepare a launch brief, a meeting note and a later decision that changes part of the plan. Ask a concrete question: "Which launch decision changed, and what source explains why?"

That question gives the wiki a job. Its value is the connection between the source, the decision and the current summary. A directory of attractive summaries is insufficient if the colleague cannot tell which claim is current.

Andrej Karpathy's LLM Wiki idea file describes persistent linked Markdown knowledge maintained from preserved sources and a set of working conventions. It is an abstract pattern, not a specific application or an endorsement of AgenticOS. The implementation below uses AgenticOS project files for that purpose.

Agree the project with Architect

Ask Architect to plan an LLM wiki for the chosen topic. Describe the material, who will use it and the output you want to maintain. Review the proposed project, its instructions and its audience before approving creation.

Creating the project creates its shared workspace and instructions. It does not automatically write the planned files or start a scheduled maintenance process. Follow the project link and create a new chat there. An existing chat cannot simply be moved into the newly created project.

The current Projects documentation describes this planning path explicitly, including an LLM wiki workflow. That is a useful foundation for a reproducible walkthrough.

Give the files clear responsibilities

Keep original material in sources/, with provenance such as the source name, author, source date and the date it was retrieved. New material can wait in inbox/ until it has been reviewed and processed.

Use notes/ for the maintained topic pages. Keep an index.md that links to the relevant notes and sources, and a CHANGELOG.md for updates and checks. These names are a proposed layout for this example, not a mandatory product schema.

Project instructions should explain those responsibilities. An agent starting a new chat needs to know where to look first and how to distinguish an original source from a generated interpretation. The original files should remain available for review.

What this layout looks like in practice

I built one from a real feed: Hacker News stories from 21 October to 4 November. The project has inbox/, notes/ and sources/hn/ folders. Every topic note is linked from index.md, and the index lists the source files behind each line, so a statement can be traced back to the story it came from. CHANGELOG.md and state.md record what changed and where the last update stopped.

The graph view shows the structure at a glance: 33 notes and 80 links, with the index at the centre and the topic notes around it.

This is one wiki on one test instance, not a benchmark.

Process the first source into a useful note

Upload the synthetic launch brief into the project's shared files. Ask the agent to read it, create a topic note and link the note to its source. The note should distinguish stated facts from inferences and unresolved questions.

Inspect the result in the project's Files tab. Open the generated note and its source. Check a specific statement against the original brief. A source link is useful only when it leads to material that supports the nearby claim.

Then inspect index.md. It should help another conversation find the topic without knowing the path of every file. Do not assume that a file tree alone gives the agent the conventions the team intended.

Add a source that changes the answer

Now add the later synthetic decision. Ask the agent to identify which existing note it affects, propose the update and preserve the source of the change. Review the revised note and the change log.

The result should let a colleague understand both the current decision and why it changed. It should not rewrite the original launch brief as though the earlier plan never existed. If the sources conflict without settling the issue, keep the conflict visible.

Compare the original source, the new information and the linked note that changes. The saved update should explain how the current answer differs from the earlier plan.

Ask from a fresh project conversation

Start a new chat inside the same project. Ask which launch decision changed and where that conclusion comes from. The shared files and project instructions persist across chats. Other chat transcripts are not automatically supplied as context.

Have the agent read the index and the relevant notes, then inspect the cited source in its answer. This tests whether the workspace carries the knowledge the example is meant to preserve. It avoids relying on the first conversation's temporary context.

In the HN Wiki project I started a new chat and asked "What's new in AI world?". The agent worked for 17 seconds in 3 steps and answered by topic, with a link on each item. It also said it had read only the headlines, scores and comment counts, not the articles themselves. An answer that states how deep it went is easier to trust than one that does not.

A knowledge collection can add indexed retrieval. It does not replace the maintained project files or automatically turn every chat attachment into a wiki. Keep those roles separate when explaining how the example works.

Make maintenance an explicit task

Ask for a check of the current notes: source support, contradictory statements, stale dates and broken links. Have the result record what was checked and what remains unresolved. A successful file write is not proof that every statement was verified.

A scheduled update needs a separate routine and the appropriate approval. Do not imply that merely creating the project starts an autonomous maintenance system. First make the manual task useful, then decide which repeated part should run in the background.

If a maintenance step needs code execution, the project must have a suitable service sandbox and permitted tools. Stored project files can support reading and writing without supplying a shell. The example's requirements should say which behavior it uses.

Share the result as team knowledge

Invite the relevant colleagues using the project's access controls. Ask another person to locate the current decision, open its source and continue the work. Keep simultaneous editing expectations realistic: shared files do not imply automatic merging of two agents' changes or a collaborative document editor.

The result to check is specific: preserved sources, a linked current note, an index, a recorded update and an answer from a fresh project chat.

The team can then use a maintained explanation of its work, with the evidence still attached. Another colleague can follow the changed launch decision back to its source.

AgenticOS workflows and tables: build a first automation

Kacper Włodarczyk — Tue, 03 Nov 2026 09:30:00 +0000

AgenticOS workflows and tables: build a first automation

AgenticOS has a visual workflow editor beside its agents. You can draw a known sequence of steps, call an agent where the task needs judgment and keep records in a Virtual Table. The pieces live in the same workspace, so a workflow can become a practical part of the team's work.

I build AgenticOS at Vstorm. This walkthrough shows how to configure the template, inspect its result and add an agent when a task needs interpretation. Drafted with AI assistance.

Start with an example you can inspect

The Public API → table template is a useful first task. It fetches a sample post from JSONPlaceholder and saves the title and body to a table. The result is concrete: a record you can open, with the workflow run behind it.

This deliberately starts with a deterministic example. You can see the workflow and the table without introducing a model's interpretation. An agent step can be added when a later task needs one.

You need an AgenticOS deployment and an account allowed to create workflows and create and edit tables. The template does not require a model-provider account, an API key for the sample source or a pre-existing table selection. It does still depend on the deployment being able to reach that external sample API.

Create the workflow from its template

Open Workflows and choose Workflow templates. Select Public API → table and complete the creation form. The server prepares the table and a configured draft together. The template starts private unless an explicit audience is chosen. That audience applies to the workflow and its table.

Check the name and who should be able to use it. Sharing is part of the example, not a detail to postpone until somebody receives a broken link. An ordinary colleague also needs the relevant permissions to see and use the resources.

The list distinguishes drafts, published workflows and archived ones. If a workflow seems to be missing, inspect the active filter before assuming it was deleted.

Read the canvas before changing it

Open the draft. Follow its connections from the starting point to the table write. Open each relevant step and inspect its configuration, input bindings and expected output fields. A binding explains where a value comes from. It should be possible to identify which response field becomes the record's title and which becomes its body.

The editor keeps Runs, Test draft and Publish visible. Use the unfinished-setup feedback when a required configuration is missing. The point of this first pass is to understand the example's data path before extending it.

A canvas can make a sequence visible, but the step configuration carries its actual behavior. Names and notes should help the next person connect the graph to the task it performs.

Test the draft and inspect the expected result

Use Test draft to try the current configuration. The expected result of the template is a sample record containing the fetched title and body. Open the run and the prepared table to check what happened in your deployment.

Look for the output rather than accepting a green-looking editor as evidence of completed work. If the fetch failed, inspect that step's error. If the fetch succeeded but no record appears, follow the values into the write step. Keep the failure visible until the result is understood.

Later runs of this template reuse the table and upsert the same example record. Repeating it is therefore a useful way to inspect its defined behavior, rather than assuming every execution should create a new row.

Use the table as a handover

Virtual Tables provide typed records with a schema, revisions and history. The console, agents, API clients and workflows can interact with those records through the platform's supported paths.

For the sample task, open the saved record and inspect its title and body. When turning the example into a team process, decide which fields the next person needs. A source reference and review status may matter more than adding another generated summary.

The current table implementation also records write provenance separately from the authorizing member. New writes can identify whether they came from a person, agent, workflow or API key. That gives the team a useful question to ask when inspecting a record: which process produced this value?

Publish deliberately

A workflow has a draft and published versions. Publishing freezes a version for execution. An edit to the draft is a proposed change to what will run, not proof that every existing execution has adopted that edit.

Review the example's inputs, audience and relevant settings before publishing. Use version history when investigating a later change. The record should let someone connect the behavior they observed to the version that produced it.

If the workflow is started by an automatic trigger, its active state matters separately. The editor exposes a way to pause that trigger. Pausing future starts is different from changing what an already-running task has done.

Add an agent for a task that needs interpretation

Once the sample data path is clear, consider a different example: an incoming request needs a suggested category and a source-linked handover. An agent can handle that interpretation inside a workflow that owns the surrounding sequence.

Give the agent step a specific responsibility. State its input and expected output, then bind those values to later steps. Use a draft test to check the example before treating the proposed automation as working.

A human decision can also be an explicit workflow step. When a process requires review, define what the reviewer sees and what happens after approval or rejection. A finished graph does not establish that the reviewer can make a useful decision from the information provided.

Choose the starting event for the actual job

AgenticOS workflows can start from several supported surfaces and triggers. The current documentation covers manual starts, chat, API calls, webhooks, schedules and table events, alongside additional integrations. Use the current trigger documentation for the one your task needs rather than relying on an old fixed count.

A good next example is a table record that begins a review process, or a webhook that starts triage. Keep the event, workflow run and resulting record connected so a colleague can follow the work.

The right follow-up is the next recognizable task, not every available node in one demonstration. Follow the input through the canvas, open its run and inspect the saved record. That connects the configuration to the result the next person will use.

Documentation: Workflows and Virtual Tables.

Claude Code and Codex as agents on your team

Kacper Włodarczyk — Wed, 28 Oct 2026 15:11:18 +0000

A general AI agent with a shell can edit code. It is not very good at it. Coding agents like Claude Code and Codex are much better, because that is the only thing they are built to do: read a repository, plan, edit, run the checks, fix, repeat.

So instead of teaching every agent to code, we let them hand the code to a coding agent. This article explains how that works in AgenticOS, the open-source system for company agents we build at Vstorm, what it needs, and what a real task looked like. Drafted with AI assistance, edited and verified by the author.

The idea in one paragraph

In AgenticOS an agent is something your team builds in the browser: instructions, a model, knowledge and a set of tools it may use. The coding agent is one of those tools. When an agent decides a task is software work, it hands the whole task to Claude Code or Codex, which runs in the agent's own sandbox until the task is done. The person in the chat watches it work, step by step, and gets back the answer, every step it took and the files it changed.

From the agent's side, the coding agent is a colleague it delegates to. From your side, it is Claude Code or Codex working on your files, with your rules, where your team can see it.

What Claude Code and Codex are

If you have not used them: Claude Code is Anthropic's coding agent and Codex is OpenAI's. Both run in a terminal, read and edit the files of a project, run commands and tests, and keep going until a task is done. Developers usually run them on their own laptop. AgenticOS runs them on a server, inside a sandbox, on behalf of an agent.

Switching it on

The coding agent is a capability in an agent's Toolbox.

It needs three things:

A sandbox. The coding agent needs a computer to work on, so the agent must have the sandbox capability with shell commands on. Publishing an agent without it is refused. The default runtime has Claude Code and Codex installed.
A harness and a credential. Choose Claude Code or Codex. Claude Code takes an Anthropic API key, or the token claude setup-token prints for a Claude Pro or Max subscription. Codex takes an OpenAI API key, or a ChatGPT sign-in. The credential lives in AgenticOS's encrypted vault and reaches the task through its environment, never on a command line.
A decision about approval. By default the coding agent runs without asking. Set Human approval to Always ask and a person confirms each task before it starts.

You can also pick the model (for example Claude Sonnet or Opus for Claude Code), a timeout for one task (15 minutes by default, up to 60) and, for Claude Code only, read-only access, where it can read the code and answer but not change anything.

Why it can work without stopping to ask

When you run Claude Code or Codex on your laptop, they ask permission before running commands. On a server nobody sits at that terminal, so AgenticOS starts them with their own prompts off. That sounds alarming until you look at where it runs: the container is the boundary. The coding agent can change any file and run any command, but only inside the agent's sandbox. Whether a task happens at all is the person's call, through Always ask.

Read-only mode is enforced by the harness, not by a list of allowed commands. A list of "safe" shell commands does not stay safe: git log --output=<file> looks like reading and writes a file. So Claude Code in read-only mode runs in plan mode with no tool that writes. Codex has no equivalent that works inside our container, so it only offers edit mode.

Watching it work

The harness runs detached in the sandbox and writes its events to a file, which AgenticOS reads every second and a half. Each step reaches the chat as it happens, in a panel under the Claude Code or Codex mark: the file it reads, the edit, the command, what it says between them. If you stop it, or it runs past its timeout, its whole process group is stopped.

Tasks in one conversation continue one session. The second task in a chat knows what the first one read. A chat never continues another chat's session, even in a sandbox several chats share.

A real task

Here is one run, from a demo organization I set up with a synthetic US team. The project is called Fall launch, and it holds a brief, a brand book, a channel plan and a launch plan another agent wrote earlier the same day.

Jordan, in the project chat, asks the Coder agent:

Build the launch page from launch-plan.md with @coding agent: one HTML file in the project, Ledgerly colors from brand-book.md, the headline from brief.md and a sign-up button.

The agent writes the brief

The Coder agent does not forward that sentence. It reads the project's files first and writes Codex a proper brief: one self-contained HTML file, the three colors from the brand book with a contrast check, the voice rules, the sections, and one important constraint it found in the brief. Every time-saved claim needs a customer quote, and there is none in the workspace, so "Close the month in two days, not ten" must not appear on the page.

The constraint was in a file the person never mentioned. The agent found it and passed it on.

What came back

Codex worked through eight actions and wrote launch-page.html into the project.

The Coder agent then reported back to Jordan:

Colors: only the three brand colors, with the button text at a 4.65:1 contrast ratio.
Headline: the product description from the brief, "Ledgerly Autopilot reconciles invoices, payments and bank lines on its own."
Left out: budget, channels, internal goals and any made-up stats or testimonials.
Checks: the HTML is well-formed, only the brand colors appear, none of the banned words.

And two decisions it would not make alone. The brief's own headline is a time-saved claim, so it left it off and marked in the HTML where it goes once someone supplies an approved quote. And the real sign-up URL was not in the workspace, so both buttons point to a placeholder until someone sends it.

One thing did not work. The agent wanted to screenshot the page to check it visually, and the sandbox ran out of disk space. It said so plainly and called the page a draft until someone opened it in a browser. That is the behaviour you want, and also a reminder that a sandbox needs room.

On a subscription

If your team already pays for Claude or ChatGPT, the coding agent can run on that plan instead of a metered API key. For Codex, a person signs in with ChatGPT once in AgenticOS. For a task, that sign-in is written to a Codex home of the task's own, outside the project's files, and removed afterwards. Because whatever Codex runs could read it, the sign-in is only handed over when the person running the agent may see it in the vault themselves. Running an agent is never a way into somebody else's subscription. And it is only handed over in a sandbox nobody else's tasks share. In a project's shared container, another person's task could read it, so there you use an API key. A Claude Pro or Max token, by contrast, is stored like a key and used by every run, whoever asked. Both vendors' plan terms may not allow a personal subscription on a shared deployment, so check them.

Your other agents do not have to use the same provider. AgenticOS works with 28 model providers (counted at the release that ships the ChatGPT plan), including your own models through Ollama or an OpenAI-compatible server such as vLLM, so a team can keep everyday agents in-house and use a subscription only for the coding work.

In a project

A project gives every chat the same container. So the files the team uploaded, the plan another agent wrote and the page Codex built all sit in one place, and the next chat picks up where this one stopped. That is what turned the demo from three separate answers into one piece of work.

Limits

No sandbox, no coding agent. A project that keeps its files without a container has no shell, and the coding agent is left out of runs there.
Codex has no read-only mode inside AgenticOS.
A subscription belongs to one person. For agents the whole company runs, an organization API key is the better fit.
It runs your code. Edit mode can run any command in the sandbox. Decide who may start a task, and use Always ask where it matters.

Try it

AgenticOS is open source (Apache-2.0) and runs on your own servers:

https://github.com/vstorm-co/agenticos
The coding agent reference: https://vstorm-co.github.io/agenticos/reference/capabilities/#coding-agent

If you hand your agents to Claude Code or Codex, I would like to hear what the first task was.

I'm Kacper, Principal Engineer and Open Source Tech Lead at Vstorm. I build AI agents and open-source tools in the Pydantic AI ecosystem. Find me on LinkedIn or GitHub.

AgenticOS Projects: a shared AI chat for your team

Kacper Włodarczyk — Tue, 20 Oct 2026 09:57:24 +0000

A chat with an AI model is a one-person thing. You ask, it answers, and then you copy the answer into Slack so the rest of the team can see it. Somebody asks a follow-up in their own chat, with half the context, and the brief you uploaded an hour ago is not in theirs.

Projects are how Vstorm AgenticOS handles work that belongs to a team rather than to one person: a launch, a monthly report, a client engagement. This article walks through what a project holds, what changes for the agents working in it, what it looks like when three people and three agents share one chat, and where the limits are. Drafted with AI assistance, edited and verified by the author.

What AgenticOS is

AgenticOS is an open-source (Apache-2.0) system for a company's AI agents that you run on your own servers. People build agents in a browser, give them documents and tools, and use them in chat, in Slack and through an API, with the model provider of their choice, including local models through Ollama. I build it at Vstorm.

What a project holds

A project is a home for ongoing work, and it holds two things every chat started in it shares.

Files, in one container. You upload a brief, a spreadsheet or a whole folder once, and every chat in the project, today's and next week's, works on the same copy. A file an agent writes in one chat is there in the next. The Files tab is a tree beside a reader that opens Markdown, PDFs, images, spreadsheets and code in place.

Instructions. Every agent answering in the project reads them after its own instructions: the tone, the deadlines, where the brand guide is. The agent is still what it is. It is just working on this.

A project also has a default agent, the one a new chat starts with. Any agent can still answer in a project chat, so the default only decides where a chat begins.

In the demo I use below, the project is called Fall launch. It holds brief.md (the launch date, the audience, a $40,000 budget and the rule that every time-saved claim needs a customer quote), channels.csv, a brand book and a checklist. Its instructions say to read those files before answering, that the budget is in US dollars, and that when a teammate replies to a plan, the agent should say whose change it applied.

What changes for the agents

Whichever agent answers, a run in a project chat works in the project's container rather than in a workspace of its own.

An agent with no sandbox is given the project's, so a plain chat agent can read and write the project's files.
An agent with its own sandbox is moved into the project's container. Its approval settings carry over, so an author who set Always ask on the shell keeps that gate.
The project's name, description and instructions are added after the agent's own instructions.

When the deployment runs a sandbox service, the container is a real sandbox session, so the files can be run as well as read. That matters for the coding agent: an agent can hand a task to Claude Code or Codex, which then works in the same container, on the same files the team uploaded. I will write about that part next week.

Working in one chat together

This is the part that makes it feel different. Several people can be in a project's chat at once.

A bar over the transcript shows who else has the chat open.
While one person writes, the others see "Tom is typing" over their composer.
A question one of them asks, and the agent's answer, appear for everybody in the chat as they are written. Nobody waits for a reload to see what the agent did.
Reply works on any message, a person's or an agent's. It quotes the message above the composer, and the quote travels with the reply.

In the demo, Maya asked the Chief of Staff agent to draft the launch plan from brief.md and channels.csv. It wrote the plan into the project as launch-plan.md, laid out the first week day by day, and finished with questions it could not answer from the files: who has a customer quote, whether the referral credits apply to every sign-up, and which dates it had assumed.

Tom had the chat open at the same time. He replied to the plan: referral credits only for referrals that convert, cap Google Search at $6k and move $2k to the webinar.

Who said what

The agent is told the chat may have several people in it, and it reads each person's turn under their name. So when Tom replies, the agent knows the change is Tom's, and it knows what "yes, do that" refers to.

The Chief of Staff answered Tom by name, applied his change and the referral rule to launch-plan.md (now revision 2), asked the Finance Analyst agent to recheck the numbers, and kept the total at the $40,000 cap. Then it listed what was still open and for whom: Julia needs to say what the extra webinar budget buys, and nobody has supplied a customer quote yet.

That last part is the instruction doing its job. A plan that names whose change it applied, and leaves the decisions it cannot make to the people who can, is a plan a team can keep working on.

Each message carries its author's name and face, so a thread several people worked on says who asked what. Renaming, archiving or deleting a chat stays with whoever started it.

Sharing and permissions

A project is private to whoever created it until they share it, with the same Share dialog an agent uses: people, departments or the whole organization, each at a level.

read lets someone see the project, its files and its instructions.
use lets them chat in it, upload files and remove them.
edit lets them change the instructions and the default agent, share the project and delete it.

A project's chats belong to its members. Whoever can see the project can read every chat in it, and whoever can work in it can continue them. A chat is not shared on its own by link: you share the project. If somebody loses access, their chat stops reaching the project's files on its next turn.

How the live part works

The presence bar and the live answer are a view, not the record: the transcript in the database is. Someone who opens the chat halfway through an answer gets everything so far and then the live stream. How that works across several API instances, with Redis, is Friday's article.

What it does not do

A few limits worth knowing before you plan a team around it.

Without a sandbox service there is no shell. The project keeps its files as a stored workspace that reads and writes the same way. Two chats writing to it at once each keep what they wrote, and where both changed one file, the later write stands. The coding agent is left out of runs there, and the agent is told why.
Questions an agent asks one person stay with that person. If the agent asks Maya to approve a step, the question waits on Maya's session. Somebody else in the room cannot answer it for her.
It is not a document editor. The shared thing is the conversation and the project's files. Two people do not type into one message together.
Deleting a project removes its container and every file in it. Its chats survive as ordinary chats outside any project.

Running it yourself

AgenticOS installs with Docker Compose on your own machine or server. It runs with a hosted model provider or with your own models through Ollama or an OpenAI-compatible server such as vLLM. Self-hosted does not mean every part is local: each provider, parser or tool you configure is a destination you choose.

Projects arrive in the release after this article's date. The repository and the full docs for projects:

If you try it with your team, I would like to hear which part of your work you put in a project first.

I'm Kacper, Principal Engineer and Open Source Tech Lead at Vstorm. I build AI agents and open-source tools in the Pydantic AI ecosystem. Find me on LinkedIn or GitHub.

Read a run's cost in AgenticOS

Kacper Włodarczyk — Mon, 12 Oct 2026 16:19:47 +0000

Most teams learn what an agent costs from the provider's invoice at the end of the month, with no way to tie a number to the task that produced it. AgenticOS puts a run's model, token usage, reported cost and tool events together in Activity. That lets you connect a cost figure to the task that produced it. This guide reads an existing demo record, then explains how to use those fields when testing an agent and setting a budget in the platform we build at Vstorm.

This article was drafted and revised with AI assistance. The amounts shown are from an existing demo capture. They are not provider invoices, current price recommendations or a benchmark of a representative workload.

Open one run

The record shows Support Copilot answering "how do I rotate a provider key?" through Slack. It names OpenRouter and anthropic/claude-opus-4.5, displays 5,397 input tokens and 170 output tokens, and reports $0.0312. A completed search_documents call appears in the timeline.

Read those fields together. The amount without the task says little about whether the run was useful. The token counts without the resolved model are not enough to interpret pricing. The successful status tells you the run completed, but the source passage and answer still need a quality check.

For this example, the screen helps you understand where to look. It does not establish what another document question will cost or how much a model switch would save. Use your own fixed task and inputs for that comparison.

Keep a comparison tied to the task

Suppose you want to shorten a support agent's prompt. Choose a small set of sample questions and preserve the expected source material. Run the current configuration and the proposed revision with those same cases.

Keep the configured model, answer, retrieved sources, status and total recorded usage. If fallbacks are enabled, the documented run row can retain the primary profile even when another model answers. Use a no-fallback test profile or separate provider evidence for a controlled model comparison. Check whether the shorter prompt preserves the instructions the task depends on. If the answer drops an important exception, lower usage does not make it an equivalent result.

Include retries and unsuccessful attempts when evaluating the complete task. Selecting only the cheapest successful run can hide the work needed to obtain that answer. If a model or provider setting changes as well as the prompt, record that change rather than attributing the difference to the prompt alone.

This is a proposed comparison procedure. No result from that experiment is reported here.

Include work performed before failure

A run can fail after it has already made billable model requests. AgenticOS keeps failed runs in history with their recorded usage. That makes failures relevant when reviewing the cost of a workflow, even if the user never received a final answer.

When inspecting a failed run, locate the stage that stopped. A tool error after model work is different from a request refused before execution. The record can help you connect usage with the progress made before the failure.

Do not assume that every failure has the same cost or that failures are necessarily more expensive than successful runs. Use the recorded events and usage for the actual task. If you retry, keep the earlier attempt beside the successful one when assessing the resources needed to complete it.

Read the Spend view's coverage

The existing Spend capture shows a warning about unpriced runs. A missing price is not a zero price: the displayed total can be a floor for the usage in that window.

Before comparing the dashboard with a provider account, check which model identifiers were priced and whether the provider or proxy adds charges outside that lookup. Also compare the same reporting period. A calendar-month figure and a rolling window can describe different sets of runs even when both appear on the same page.

Model usage is only one cost component of an agent workflow. External tool services, sandbox compute and storage can have separate bills. Keep those components visible when estimating the cost of operating the whole task rather than treating the model-cost field as the entire invoice.

Set the budget on the intended configuration

AgenticOS checks accounted spend before model requests. If the applicable limit has already been reached, the next request can be refused. Use the published configuration when checking which limit a run is meant to use; changing a draft setting is not the same as publishing it.

A useful trial is to use a disposable configuration with a deliberately small limit and inspect the refusal path. Check the run's status and recorded usage, then confirm which setting caused the stop. This establishes the behavior of that trial rather than a universal upper bound on every possible workflow.

The budget is not a reservation for the full future bill. A request can incur cost after passing its check, and concurrent or already committed work may not yet be reflected in the accounted total. Pricing gaps add another reason that a displayed amount may not describe all usage.

Keep those conditions beside the cap when deciding how much traffic to allow. A spending limit and a request-rate limit answer different questions, and external-service charges need their own controls.

Look at the input behind the number

Input usage can include instructions, tool definitions, retrieved material and conversation history. The actual request also depends on runtime behavior such as selection, caching and history processing. Counting the words visible in the chat does not reproduce that request.

If input grows during a long task, inspect what is being retained. Compaction can summarize history, but the summary may omit details the next step needs and producing it can require work of its own. Compare both the task result and total usage before deciding that the change helped.

The same approach applies to a smaller model: keep the source inputs and success criteria fixed, inspect the answer and record the whole task's usage. A cheaper individual request is useful only if it still does the work you need or reduces the complete workflow's cost at an acceptable quality level.

Keep a useful run record

For your first trial, retain the task input, published configuration, resolved model, output and usage together. Add unsuccessful attempts and identify any external costs the platform does not count. That gives a later prompt or model change something concrete to compare with.

The governance guide explains budgets and their accounting limits. The demo screen above shows how to read one run; a workload estimate needs observations from the tasks and traffic you actually intend to support.

Which of your agents would you want to see a cost for first, and what would you compare it with?

I'm Kacper, Principal Engineer and Open Source Tech Lead at Vstorm. I build AI agents and open-source tools in the Pydantic AI ecosystem. Find me on LinkedIn or GitHub.

Reverse-engineering a web page into a Claude Code skill

Kacper Włodarczyk — Fri, 09 Oct 2026 10:41:45 +0000

I saw a long read on Frontstory, a Polish investigative outlet, that tells its story by scrolling over one large illustrated map. You read a short card, and the map glides to a city. A few cards later it pulls back to show the whole region, then zooms somewhere else. The format is usually called scrollytelling: the text scrolls, and a picture behind it changes with every paragraph.

I wanted pages like that for explaining how AI systems work, so I asked Claude Code to take the page apart and teach itself to build them. This article follows what it did and where I had to step in. It was drafted and revised with AI assistance. Most examples shown use invented data.

The prompt

The whole request, translated from Polish, was this:

Analyse the structure of https://frontstory.pl/sabotaze. It scrolls, content appears, and it's nicely animated. Could you add a skill to our system for creating pages like this in HTML? Analyse the format thoroughly, then make three examples for the Gallery.

The skill was for Content OS, the internal system we use at Vstorm to plan, research, draft and check content. A skill there is the same thing as a Claude Code skill anywhere: a folder with a SKILL.md that tells the agent how to do one kind of job, plus whatever scripts and references that job needs. Content OS is internal, so there's nothing to install from this article. The approach is the part worth taking.

What the agent read

Claude Code downloaded the page and read its HTML. It also opened the page in a headless browser and took screenshots at desktop and phone widths, to see what a reader sees rather than only what the source says. Those copies stayed in a temporary folder. None of the page's text, images or code went into our repository.

The page turned out to be a single hand-written HTML file with no framework:

The stage. One SVG drawing fixed to the screen: the map as an image, with about fifteen illustrations placed on top of it.
Camera targets. Fourteen invisible rectangles in the SVG, each drawn around something a shot should show.
Steps. Thirty-six text cards. Each names a camera target and the illustrations to show while it is on screen.
The camera. When a card becomes active, a script measures its target rectangle and animates the SVG's viewBox toward it. Changing the viewBox is what makes the drawing appear to zoom and pan.
The trigger. An IntersectionObserver decides which card is active as you scroll.

It also noticed the rhythm, which turned out to be the real lesson: an establishing shot of the whole map, a zoom to one place, several cards held on that place while the text continues, a pull back, the next place. Most cards change only the text. The camera moves perhaps every third card.

What it built

After a few minutes of reading, the agent went straight to code. In order: a small runtime that moves the camera and shows layers, a stylesheet, a build script, a recorder that films a page, then three examples, and only then the skill. Next to the skill it saved its teardown of the original page as a reference file, with the table of parts above and the rhythm.

That file ended up being one of the most useful things in the whole skill. It explains the format in plain terms, and every later page starts from it. Asking for that teardown as its own deliverable, before any code, is a cheap way to check that the agent understood the format before it builds on that understanding.

A single article and a tool that makes many pages have different jobs, so the teardown also lists where our version differs:

Any card height works. A card becomes active when its top crosses one line on the screen, however long the card is. Long cards on a narrow phone screen were the case that drove this.
One camera at a time. A new camera move cancels the running one and starts from wherever it got to.
Nothing remote. The stage is vector, fonts are embedded, and the build refuses anything loaded from another server. The finished page is one HTML file that works offline.
Typos fail loudly. A card inherits what it leaves out from the card before, and the build rejects an attribute it doesn't know or an id that points at nothing.
Reduced motion. For readers who ask their system for less motion, the camera cuts instead of gliding.
Scroll-scrubbed animation. A card can publish how far through it the reader is, from 0 to 1, so something on the stage can grow or fill as you scroll.

None of this is a criticism of the original. It's what changes when the same idea has to survive in pages written by an agent, for subjects nobody has seen yet.

How the skill works

The skill tells the agent to design the story before drawing anything. First a beat sheet: one row per step, with the sentence the card says, what the stage shows and where the camera is. Then one stage, drawn once in one SVG, with invisible cam-* rectangles around everything a shot will frame and a .layer group for everything a step will reveal. Then the cards.

A card is ordinary HTML with a few data attributes. This one, from the example about agent requests, zooms to the app and shows three parts of the drawing:

<section class="step" data-camera="#cam-app" data-show="#b-request, #p-ask, #b-wrap">
  <h2>The app adds what the model needs</h2>
  <p>The model sees nothing but text. The app sends your message together with
     standing instructions and a description of every tool it may use.</p>
</section>

A build script turns that story.html into the finished page. Before writing anything, it checks that every camera and layer a card names exists in the drawing, that the page has a title, a language and alt text, and that nothing loads from the network. Then it opens the page in a headless browser, scrolls to every step and fails if one never becomes active, which no static check can see. With --film it also records the page as a video at reading pace, for channels that take video and not interactive pages.

The checks matter because an agent can easily write a card that points at #cam-tools when the rectangle is called #cam-tool. Without the check, that card would just do nothing, and nobody would notice until a reader did.

My first review, and the apology

The first version came back about half an hour after the prompt. I opened the examples and wrote, roughly: only the text moves and the background doesn't, the point is that the background can change too. Agent request map is nice, but the others are weak.

Then, in the same message: damn, sorry, I put that badly, the examples are actually nice. Make more of them and vary the style so there's more choice. Five to ten more.

The agent took both halves seriously. The next round added three more ways for the stage to change:

Scenes. A card can name a mood, and the stylesheet recolours the whole stage for it. In one example a city goes from dusk to night to morning as you read.
Depth. Parts of the stage can sit at different depths, so every camera move becomes parallax.
Rearranging. A page script can move the stage's own elements. In another example 400 dots, one per invented support ticket, gather into piles by topic and then stack into a bar chart.

The skill now says it plainly: a page where only the text moves is an article with a picture.

Nine examples in different styles

From the first prompt at 19:49 to the merged pull request with nine examples took about two hours. That includes two review rounds by Codex on the pull request. It found things like a page referring to files that a single-file page would lose, and old video files left behind by an earlier build, and Claude Code fixed them. I merged after the second round. A third round came back after the merge with eight more findings, which are still open.

Each one uses a different visual style and a different way of moving the stage:

a request travelling through an AI agent, with the camera hopping across one diagram
a night on call, told across a city that changes from dusk to day
a week of support tickets as dots that sort themselves
retrieval in a RAG system, with text chunks turning into points
seventy years of AI history on one long, newspaper-styled page, citing the real papers
a conversation between an agent and an MCP server, printed in a terminal as you scroll
an eval catching a regression, in loud full-colour scenes
why retries need backoff, on a chart the page computes itself
a context window filling up and being compacted as you scroll

They all sit in the Gallery of our panel, where each opens as a live page in a sandboxed frame, with a phone-width toggle.

I asked for different styles so there would be more to choose from. In hindsight they also show something else: one example only proves the agent can reproduce what it saw, while nine in different styles show the technique got separated from its original subject.

Doing this yourself

This was one evening with Claude Code, but I'd expect the same steps to carry over to other formats and other coding agents:

Point the agent at the real thing. Ask it to download the page and open it in a browser at desktop and phone width, not just to guess from a screenshot.
Ask for the teardown as its own file. A short reference that lists the parts, how they connect and what the rhythm is. Read it. If you can't follow it, the skill built on it will be shaky too.
Have it list what a reusable tool must do differently. One page and a generator have different jobs.
Then the skill. A SKILL.md with the method, a template to start from and a script that checks the output, so the agent's mistakes fail loudly.
Ask for several examples in different styles. They test whether the technique survives a new subject.
Review honestly. My reaction to the first version produced the biggest change of the evening, apology included.

And borrow the technique, never the content. The skill itself says so: a page that reuses another publication's structure takes none of its text, drawings or branding.

What this doesn't show

The skill is new. Our publication records list nothing made with it yet, so it hasn't met real readers or subjects with messy data. Most examples are teaching pieces with invented numbers. Eight review findings are still waiting. And the two hours were possible because Content OS already had a build pipeline, a Gallery and checks for other formats that the new skill could plug into.

Still, it's a good way to learn a format. Instead of only admiring a page, I can ask an agent to read it properly, build a tool from it and leave an explanation of how it works.

Which format have you seen lately that you'd want a coding agent to take apart?

The original that started it: Frontstory, "Paczka z bombą", with the interactive visualisation by Anastasiia Morozova and illustrations by Alisa Szorochowa.

I'm Kacper, Principal Engineer and Open Source Tech Lead at Vstorm. I build AI agents and open-source tools in the Pydantic AI ecosystem. Find me on LinkedIn or GitHub.

AgenticOS: self-hosted AI agents your whole team can improve

Kacper Włodarczyk — Wed, 07 Oct 2026 11:39:00 +0000

AgenticOS: self-hosted AI agents your whole team can improve

Vstorm AgenticOS is an open-source, self-hosted platform for company AI agents. It lets you build your own AI agents in a browser, give them access to your documents, and choose the tools they can use, on infrastructure you control. This week it has a new README and two decks built on the real product screens, and this article is the longer version of them.

I'm Principal Engineer and Open Source Tech Lead at Vstorm, and I build AgenticOS, so read this as the maintainer's account rather than a review. The article was drafted with AI assistance. Every product fact in it was checked against the repository at release v0.0.516 or the README pull request that ships this week.

The problem it is built around

Most agent frameworks give you a library. You write Python, you deploy it, and every change to an agent's behaviour is a pull request, a review and a release. That is the right shape for a product feature. It is a poor shape for the many small agents a company actually wants, and the AgenticOS docs put the reason in one sentence: the person who knows what the agent should say is not the person with commit access.

So AgenticOS splits the work along that line. Engineers add capabilities in typed Python. The people who know the work write the instructions, upload the documents and maintain the procedures, in the browser. Colleagues use the published agent in web chat, Slack, Mattermost or Telegram, and developers call it through the API.

The promise on the README is the short form of that: AI agents your whole team can use and improve.

What is new this week, and what is not

There is no 0.1.0. AgenticOS is still 0.0.x: the public history starts on 28 July 2026, and releases v0.0.1 to v0.0.516 followed between 2 August and 1 October. Treat the interfaces as young.

What changed is how the project explains itself:

The README now opens with what AgenticOS is and who it is for, then what you can do with it, what ships today and where it stops.
A short introduction deck (14 slides at launch) covers the problem, the idea, the product, its controls and limits, and how to start. A longer product tour (44 slides at launch) goes through every screen in detail.
The README and the decks include a list of where it stops today. The parts that matter most for an evaluation are at the end of this article.

Building an agent in the browser

An agent starts as instructions, a model and a set of tools. You choose them in the builder, publish a version, then test it in chat. Earlier versions stay readable, and you can roll back.

Three kinds of company knowledge sit beside the agent:

Skills are reusable procedures, such as how to review code or write a report. You maintain one once and attach it to several agents.
Context is standing knowledge, such as a glossary or a policy. The agent gets it in the prompt or reads it on demand.
Knowledge bases make uploaded documents searchable, so an answer can come from your own files and cite the passage it used.

With a container sandbox configured and command execution switched on, an agent can also read and edit files, run shell commands and execute Python or JavaScript. If you have used Claude Code or Codex, that part will feel familiar. What AgenticOS adds is the shared workspace around it: company knowledge, published agents and organisation access controls. What any agent achieves still depends on its model, tools and instructions.

If you'd rather watch than read, the README has a 37-second recording of one run from 1 October: an agent reads a brief in Notion, researches our GitHub repositories and publishes an interactive page with its sources. The recording is edited, with the waiting cut out, and it runs on our own projects, so it is an integration example, not a customer story.

Three controls an IT or security reviewer will ask about

Putting agents in front of a whole team raises three questions before anyone asks about features. What can it spend? What can it do without asking? What happened yesterday?

The budget is checked before every model request

Each agent can have a monthly budget, and a new organisation starts with one ($100 by default). AgenticOS checks both before each model request, not after. The docs explain why: checking afterwards means the request that broke the budget was already paid for.

There is a limit worth knowing before you rely on it. A run's cost lands on its record when the run finishes, so runs that start together cannot see one another. Fifty parallel runs against a cap that is one call short of full can each read the same under-cap total and overshoot it by up to their combined cost. If you need a strict cap, run those agents through one queue.

Sensitive tools wait for a person

A tool that acts on the outside world parks the run and waits. A person sees the call, approves or rejects it, and the decision is recorded with who asked and who decided. You set this per tool or per capability. In the screenshot the same test account asked and decided. The permission to decide approvals is its own, and the built-in Operator role holds it without being able to edit agents.

The limit here is coverage. The gate applies to the platform's own capability tools. Tools from an MCP server (the Model Context Protocol, an open standard for connecting agents to external tools) pass through it only when a web-chat session is set to Ask about everything, and a tool that runs inside the model provider never reaches the local gate. Test the approval policy for the tools you actually enable.

Every run is recorded

Every run lands in run history with the agent version that executed, the tools it called, the tokens and the cost. Because the version is recorded, a run from last week still makes sense after someone rewrites the agent.

Governance actions go into a separate audit log: approval decisions, sharing and membership changes, secret rotation, exports and more. Each entry carries a hash over its own contents with the previous entry's hash folded in, per organisation, so editing, reordering, inserting or deleting an entry shows up when the chain is verified. That is detection, not prevention. It does not protect against someone holding the database's own credentials, who can rewrite a row and recompute the chain. And not every write is audited. Knowledge-base edits, for one, are not.

For developers: code defines, configuration composes

AgenticOS is built on Pydantic AI, the Python agent framework from the Pydantic team, and pydantic-ai-harness, a set of ready-made capabilities for Pydantic AI agents such as planning and tool-output limits. The backend is FastAPI with PostgreSQL (pgvector for the document search), Redis and Prefect for background and scheduled jobs, and the console is Next.js.

The built-in capabilities are typed Python that an engineer writes, tests and registers. The console can only switch on what code registered, which the docs call "code defines, configuration composes". That is the boundary that lets the person who owns an agent's instructions change them without a release.

MCP servers are the exception, and it is worth knowing before you choose a platform for a team. A builder or an admin connects one by pasting its URL, with no code change, and its tools sit outside the approval gate described above unless a chat asks about everything. Decide who holds the Builder role with that in mind.

Running it yourself

The quick start is a Docker Compose deployment through an installer script, on macOS, Linux or Windows under WSL2. You can run it with --check first to test the prerequisites without installing anything, or read the script, or follow the manual installation guide. You need access to a model: a hosted provider, or a local model through Ollama or an OpenAI-compatible server such as vLLM, both of which serve open-weight models on your own hardware.

Self-hosting the console does not make everything local. A hosted model, a cloud document parser or an external tool still receives the data you send it, so review the destinations you configure.

Two things from the repository that a self-hoster may find more useful than a feature list:

The first bottleneck was the database pool, not CPU. On 16 September we load-tested one laptop: one worker, a stub model instead of a paid provider, 4,740 requests across a ramp, a sustained rate, a burst and a recovery. With the default pool of 5 connections plus 10 overflow, 1,537 requests failed. With 20 plus 30, 13 failed. CPU peaked at about 90 percent of one core in both runs. The shipped defaults are still 5 plus 10, so if you expect parallel load, raise DB_POOL_SIZE and DB_MAX_OVERFLOW first. This is one machine and a stub model, a request rate rather than a user count, so it says where the first wall is, not what a production deployment can carry.

There is a HIPAA configuration profile, and it is not a certification. It covers the technical safeguards of 45 CFR §164.312 and nothing else: TLS to Postgres, Redis and the browser, a long vault key, a local model, local traces, single sign-on (OIDC or Kerberos), invite-only or closed signup, six years of audit retention and the audit chain. A doctor command checks the profile and exits non-zero when something is missing. The administrative and physical safeguards, encryption of content at rest and any business associate agreement remain the operator's job, and the profile says so.

What it does not do yet

This is the short list for an evaluation:

No ACL mirroring. Permissions from SharePoint or Google Drive are not copied per user into a knowledge base. Scope the credential and share the collection with the right group.
No SAML, no SCIM, no native MFA. OIDC, LDAP and Kerberos sign-in work. A SAML-only identity provider can come in through a broker such as Keycloak, and multi-factor is your identity provider's job.
No Kubernetes manifests. It is Docker Compose on one host today.
No reranker. Retrieval is vector search with options.
No visual workflow builder. It is in development and not in any release.
Budgets can be overshot by parallel runs, as described above.

The README and the decks add a few more, such as no built-in Microsoft 365 trigger.

Try it

Start with the introduction deck if you want the shape of it: https://vstorm-co.github.io/agenticos/presentation/

For every screen in detail, the product tour: https://vstorm-co.github.io/agenticos/presentation/tour/

Then the quick start and the document-assistant walkthrough, which uploads a handbook, asks questions and checks the answers against cited sources: https://github.com/vstorm-co/agenticos

It is Apache-2.0. Issues and pull requests are open, and I'd especially like to hear what would stop you from running it: a missing sign-in method, a deployment target, a control your security team would ask for.

I'm Kacper, Principal Engineer and Open Source Tech Lead at Vstorm. I build AI agents and open-source tools in the Pydantic AI ecosystem. Find me on LinkedIn or GitHub.

How We Built the AgenticOS Desktop Pets

Kacper Włodarczyk — Thu, 10 Sep 2026 11:27:42 +0000

Amigo walks around the desktop, follows the cursor with his eyes, and says “No more caramba.” Move the cursor back and forth over him and he closes his eyes with a little heart above his head.

He's one of five pets in the AgenticOS desktop app. You can also pick a ghost, a small terminal on legs, a sprout, or a round creature with an antenna. They share the same movements, but each has its own appearance and lines.

AgenticOS is an open-source project I'm building at Vstorm for creating and using AI agents. The pet is a small extra in its Tauri desktop app. This article is about how that extra works: drawing the characters, deciding what they do, and keeping them on the desktop beside the main window.

Amigo has his own window, so he can stay visible when the main app is minimised.

Drawing a pet from separate parts

The artwork starts as a small grid. Each character in the grid represents a colour, and a dot represents a transparent pixel. The body, eyes, feet and other details are placed on top of one another to produce a frame.

That means we can change the expression without drawing the whole character again. A blink uses closed eyes in place of open ones. A wave moves the arm. A hop lifts the parts together and then brings them back down.

Each pet has its own body and coordinates for those parts. The ghost has no feet, while Amigo has a sombrero and moustache. The animation code works with those differences, using the parts that each character provides.

The definitions live in pet-sprites.js. In the same file, a waving animation is described by these two positions:

wave: () => [{ arm: "up" }, { arm: "down" }],

That's an excerpt from the animation table, rather than a standalone program. The renderer combines each position with the selected pet's artwork. Other entries describe blinking, walking, sleeping and hopping in the same way.

For these simple characters, that gives us a shared set of movements to work on. A new pet needs artwork and part positions, then it can use the existing animations. A character with a very different shape or movement would need more work. Sprite sheets would still be a reasonable choice for more detailed, individually drawn animation.

Deciding when to move

Drawing the frames is separate from choosing what happens next. That second part lives in pet-engine.js.

When left alone, the pet spends most of its time standing still. It occasionally looks around, walks a little, or dozes. At night, it dozes instead of choosing another stroll. When it reaches the edge of the usable screen area, it turns back.

Those decisions are functions with explicit inputs. The choice of the next behaviour takes a random-number function and the hour. Walking takes the current position, direction, elapsed time and screen boundaries. None of those calculations needs to open a desktop window.

That makes the rules easier to check independently. You can supply a particular hour or position and inspect the result without waiting for a pet to happen to do the right thing on screen. The repository includes tests alongside the pet code for these behaviours.

Making the cursor interaction feel intentional

The eyes follow the cursor, with a small area around the centre where they keep looking straight ahead. Otherwise, small pointer movements near the middle would keep changing their direction.

Stroking needs a different rule. A cursor passing over the character once shouldn't trigger the same reaction as moving back and forth over it. The engine tracks changes in direction within a short time window. Enough changes trigger the closed eyes and heart animation.

Clicking makes the pet wave and say something. Double-clicking brings the AgenticOS window forward. Hovering reveals a “+ New chat” button, and the right-click menu lets you change the character or hide it.

These interactions give the pet a few useful links back to the app without requiring it to move constantly. It also respects the operating system's reduced-motion setting by standing still while remaining draggable.

Giving it a window of its own

The pet lives in a transparent, always-on-top Tauri window. The main console is a separate window, so minimising or closing that window doesn't remove the pet while the app is still running.

The app remembers the selected character, whether it's visible, and where it was left. On the next launch, you don't need to pick the same pet and drag it back into place.

The console itself loads the web app from the configured AgenticOS server. You still need that server running. Installing the desktop shell doesn't install the platform or make it available offline.

One current limitation is that the pet doesn't show agent activity. A sleeping Amigo doesn't mean your agent has stopped, and a wave doesn't mean a task has finished. Connecting those events to the pet would require an explicit connection between the web app and the desktop shell. For now, its reactions come from the interactions described here.

Where to look in the code

If you'd like to explore the implementation, start with these three files in desktop/ui:

pet-sprites.js holds the artwork, part positions and animation frames.
pet-engine.js handles behaviour, movement and cursor interactions.
pet-lines.js contains what each character says.

The desktop documentation covers the Tauri setup and commands for running it against your own AgenticOS installation.

Changing a line in pet-lines.js is a small place to start. Changing the artwork gives you something more visible to play with. You can explore either without needing to understand the agent builder or the rest of the platform first.

Kacper Włodarczyk, building AgenticOS at Vstorm.

24 Claude Code Skills to Fix Your AI Stack: Introducing production-stack-skills and content-skills

Kacper Włodarczyk — Mon, 20 Apr 2026 11:59:05 +0000

78% of Fortune 500 companies are adopting AI coding assistants. 45% of that generated code ships with security vulnerabilities. On the content side, 76% of readers identify AI-written text within three seconds, and engagement drops around 47% when they do.

Those three numbers describe the same problem from two angles: AI outputs need guardrails, whether the output is code or writing. Today we're shipping two Claude Code skill packs that sit on those guardrails.

A Claude Code skill is a packaged slash command that augments your AI coding agent with a specific expertise, readable via SKILL.md and invocable from any AGENTS.md-compatible runtime. The Skills Wave is two of those packs, released the same day because the failure modes on both sides of the AI workflow deserve the same fix.

I'm Kacper, AI Engineer at Vstorm, an Applied Agentic AI Engineering Consultancy. We've shipped 30+ production AI agent implementations and open-source our tooling at github.com/vstorm-co.

production-stack-skills: 10 Claude Code Skills for Production-Ready AI Code

production-stack-skills is a 10-skill pack that audits AI-generated code across six weighted categories and hands back a 0 to 100 production-readiness score with a prioritized action plan.

The flagship command is /production check. You point it at a repo, it reads the FastAPI routes, Postgres migrations, Dockerfiles, and config, and returns:

A headline score (e.g., "Production Readiness: 34/100")
Six category scores: security, error handling, observability, deployment, data layer, code quality
A Quick Wins section with point deltas
An Action Plan sorted by weighted impact

In first internal runs across client repos, Quick Wins alone consistently moves the score about 30 points. That's the number I'd quote if a CTO asked "what does running this for a morning actually buy me".

The other nine skills split by surface area: /production review, /production planner, /production fastapi, /production postgres, /production docker, /production deploy, /production monitoring, /production security, /production error-handling. Each is a focused slash command rather than a sub-mode of a monolithic agent.

content-skills: 14 Brand-First Skills That Kill AI Slop

content-skills is a 14-skill pack with a /brand/ directory at its core, so every piece of content generated after a five-minute brand interview reads your BRAND.md, VOICE.md, VISUAL.md, and voice samples before writing a word.

Run /content setup once. Five questions. It writes /brand/. From that moment, every content skill auto-reads that directory on every invocation.

The exit point is /content audit. Score any piece of content 0 to 100 on voice consistency, anti-slop markers, visual consistency, and brand alignment.

Between setup and audit sit 12 production skills: strategy, calendar, blog, twitter, linkedin, reddit, hackernews, presentation, infographic, image, video, repurpose.

One Install, Dual-CLI, Uninstall-Safe

curl -fsSL https://raw.githubusercontent.com/vstorm-co/production-stack-skills/main/install.sh | bash
curl -fsSL https://raw.githubusercontent.com/vstorm-co/content-skills/main/install.sh | bash

Each install mirrors the skills into both ~/.claude/ (Claude Code) and ~/.agents/ (Codex, Amp, and anything AGENTS.md-compatible). You don't pick the runtime up front. A skill written for Claude Code works identically in Codex.

Uninstall is boring by design. /content-skills uninstall removes the skills. Your /brand/ stays.

Both repos are MIT.

Why Two Packs Shipped the Same Day

In 30+ production AI agent deployments at Vstorm, the failures cluster into two shapes: code that passes demo but fails the first prod incident, and content that sounds like the AI wrote it because the AI wrote it.

One pack addresses the first. The other addresses the second. Both use the same architecture because the lesson that skills beat monolithic agents applies to both. You don't want "one AI that does everything". You want 24 small, composable, auditable slash commands that you can swap, tune, or remove when they stop pulling weight.

Key Takeaways

production-stack-skills ships 10 skills with a 0-100 scorer and Quick Wins section that typically moves scores +30 in under five minutes.
content-skills ships 14 skills built around a /brand/ directory auto-read on every invocation.
Both packs install via one curl command, mirror into ~/.claude/ and ~/.agents/, work on Claude Code, Codex, and any AGENTS.md-compatible runtime.
Skill-first architecture beats monolithic agents for auditability and local updates.
Both repos are MIT.

Frequently Asked Questions

What are Claude Code skills and how do I install them?

Claude Code skills are packaged slash commands backed by a SKILL.md file that extends a coding agent with specific expertise. You install a skill pack with a single curl command that mirrors files into ~/.claude/ and ~/.agents/. After install, slash commands become available immediately without restart.

What's the difference between production-stack-skills and content-skills?

production-stack-skills audits and hardens AI-generated code across security, error handling, observability, deployment, data, and code quality, returning a 0-100 score. content-skills audits and produces on-brand content using a /brand/ directory you set up once, returning voice-consistency and anti-slop scores.

Do these skills work with Codex or only Claude Code?

Both. Each install script mirrors files into both ~/.claude/ and ~/.agents/, so the same skill works in Claude Code, Codex, Amp, and any AGENTS.md-compatible runtime without modification.

How long does `/production check` take on a real repo?

On a typical FastAPI + Postgres repo of a few thousand lines, about a minute. The Quick Wins section is what you act on first, usually under five minutes to apply.

When should I use a Claude Code skill instead of writing a full agent?

Use a skill when the job is scoped expertise invoked explicitly (audit this, write a post in my voice). Use a full agent when the job is open-ended, multi-step, and requires planning across tools. Skills are composable building blocks; agents orchestrate them.

Get Started

production-stack-skills: github.com/vstorm-co/production-stack-skills
content-skills: github.com/vstorm-co/content-skills
Full writeup: oss.vstorm.co/blog/skills-wave-launch-claude-code-skills

Follow me on LinkedIn for the follow-ups: Wednesday's production deep-dive, Thursday's content walkthrough, Friday's "8 Lessons from Shipping 24 Claude Code Skills".

Full Observability in AI Agents: What We Added to the pydantic-deepagents TUI

Kacper Włodarczyk — Sat, 18 Apr 2026 09:58:43 +0000

Full Observability in AI Agents: What We Added to the pydantic-deepagents TUI

This is a cross-post. Canonical version: oss.vstorm.co/blog/ai-agent-tui-observability-pydantic-deep/

This week I covered how pydantic-deepagents handles stuck loops, context window blindness, and frictionless installation. Today: what you actually see when all of that runs.

The problem with invisible agents

When an AI agent runs, a lot happens between your prompt and the response. The model reasons. It calls tools. Each action burns tokens and costs money. Without observability, you're flying blind — you can't debug, optimize, or trust what's happening.

pydantic-deepagents v0.3.5 — the modular agent runtime for Python — reworks the TUI to surface everything.

What changed

Per-turn token usage

Below every assistant response:

in:2.1K · out:412 · total:2.5K · reqs:3

in = input tokens, out = output tokens, total = turn total, reqs = API calls in this turn.

Cumulative cost in the header

pydantic-deepagents  in:45K out:3K · $0.12

Updates after each response. You always know the running total.

Thinking streamed live → collapsed

Model reasoning appears as dimmed text while running. Collapses to a one-line summary when done. Watch the agent reason without drowning in it.

Side panel on startup

Opens automatically when terminal ≥100 chars wide. Shows subagents before any task:

Subagents:
• planner (idle)
• research (idle)

Status updates as agents are delegated work.

All tool calls visible

Todo tools (read_todos, write_todos, add_todo, update_todo_status, remove_todo) were previously hidden. Now surfaced. Every agent action is visible.

Session saved on crash

_save_session() is now in a finally block. Crash, exception, keyboard interrupt — messages.json is always written. No more lost sessions.

Subagent logs: 20K chars (was 2K)

tool_log.jsonl now stores full subagent output. Critical for /improve — the pipeline that extracts learnings from sessions (more on that tomorrow).

The full layout

┌─────────────────────────────────┬──────────────────┐
│ pydantic-deepagents  in:45K out:3K · $0.12         │
├─────────────────────────────────┼──────────────────┤
│ [thinking... dimmed text]       │ Subagents:       │
│ [collapsed to summary]          │ • planner (idle) │
│                                 │ • research (idle)│
│ Agent response here...          │                  │
│ in:2.1K · out:412 · $0.04       │                  │
└─────────────────────────────────┴──────────────────┘

Try it

curl -fsSL https://oss.vstorm.co/install.sh | bash

GitHub: github.com/vstorm-co/pydantic-deep

Observability is how you debug, optimize, and trust your agent. A black box is a liability.

What's the first metric you check when debugging an agent run?

Browser Automation + /improve: AI Agents That Browse the Web and Fix Themselves

Kacper Włodarczyk — Fri, 17 Apr 2026 12:20:41 +0000

This week I shipped 5 versions of pydantic-deepagents — the modular agent runtime for Python. Today: the two features that close the loop — browser automation and session-based self-improvement.

Part 1: BrowserCapability — 9 Playwright Tools

pip install 'pydantic-deep[browser]'
playwright install chromium

from pydantic_deep.capabilities import BrowserCapability

agent = create_deep_agent(
    model="anthropic:claude-opus-4-6",
    extra_capabilities=[BrowserCapability(
        allowed_domains=["github.com", "docs.python.org"],
        auto_screenshot=True,
    )]
)

The 9 tools: navigate, click, type_text, get_text, screenshot, scroll, go_back, go_forward, execute_js.

Safety design: Single-tab (predictable state), domain allowlist (agent can't navigate outside allowed domains), automatic popup interception, content truncation to prevent context overflow.

Browser lifecycle: Chromium starts before the agent run, stops after — whether the run succeeds, fails, or is cancelled. No orphaned processes.

CLI:

pydantic-deep tui --browser --browser-headed   # visible window
pydantic-deep run "research X on GitHub" --browser --sandbox docker

Bug fix: Browser tools now force kind='function' — they never trigger approval dialogs mid-task.

Part 2: /improve — Session-Based Self-Improvement

After each session, /improve analyzes the full run and extracts:

UserFactInsight — what the agent learned about you and your preferences
AgentLearningInsight — strategies that worked, failure modes encountered

Both write to MEMORY.md. Next session loads MEMORY.md automatically.

Key finding: We tested summaries vs raw tool traces as input to the synthesis step. Raw traces performed significantly better — summaries compress away the signal that matters. /improve reads from tool_log.jsonl (written per session), not from a summary.

The loop: agent runs → /improve extracts insights → MEMORY.md grows → next run starts smarter.

This Week's Full Stack

Monday: StuckLoopDetection | Tuesday: LimitWarnerCapability | Wednesday: curl install | Thursday: Docker sandbox | Today: browser + /improve

An agent that detects loops, knows its context limits, installs in 30s, runs in Docker, browses the web, and learns from every session.

Full breakdown: https://oss.vstorm.co/blog/browser-automation-improve-ai-agents-pydantic-deep/

GitHub: https://github.com/vstorm-co/pydantic-deep

curl | bash for AI Agents: One-Command Install for pydantic-deep

Kacper Włodarczyk — Wed, 15 Apr 2026 11:57:47 +0000

The standard Python AI tool install experience:

Install Python (which version?)
Create a venv
pip install
ModuleNotFoundError: No module named 'textual'
pip install again with correct extras
Figure out PATH

Seven steps. Fifteen minutes. That's before you've even seen the tool.

We fixed this for pydantic-deep — the modular agent runtime for Python:

curl -fsSL https://raw.githubusercontent.com/vstorm-co/pydantic-deep/main/install.sh | bash

That's it.

What install.sh does

Detects whether uv is installed
If not: installs uv via the official Astral installer
Runs uv tool install "pydantic-deep[cli]" — isolated environment, binary available globally
Verifies the install
Prints PATH fix instructions if needed

No virtual environment management. No extras guessing. The cli extras group includes everything including textual (which was the original bug — it was missing from the base install).

Self-update

pydantic-deep update

Uses uv tool upgrade if available, falls back to pip. One command to stay current.

Startup notifications

Every invocation checks PyPI for updates silently (2-second timeout, 24-hour cache):

Update available: v0.3.6 → v0.3.7  Run: pydantic-deep update

Never blocks startup.

Why uv?

uv tool install is designed exactly for this use case — isolated tool environments, global binary access, no activation required. Fast, well-maintained, increasingly standard for Python CLI tooling.

Alternatives considered: pipx (slower, needs separate install), Homebrew tap (maintenance overhead), native binary (too brittle for dynamic imports).

Full write-up with implementation details: oss.vstorm.co/blog/pydantic-deep-one-command-install-curl-bash

GitHub: github.com/vstorm-co/pydantic-deep

What's the worst install experience you've had with an AI/ML tool?