DEV Community: Tomas Grasl

Claude Code built the app. I refused to let it publish itself.

Tomas Grasl — Thu, 15 Oct 2026 14:38:07 +0000

Claude Code can write an app, fix a broken import, and hand me a working preview. That still does not mean it should decide when the app becomes public.

This is the line I kept coming back to while building drobek. The coding agent should be fast inside the build loop. Publishing should remain an explicit human decision.

Drobek launched on Product Hunt today. The short version fits into 33 seconds:

The useful part is the contract behind the animation.

The agent gets a loop, not a magic deploy button

For the normal path, the agent works through three MCP tools:

create_app
    -> starter, app ID, briefing, preview URL

write_files
    -> immutable version, compile result, preview URL

publish
    -> the selected compiled version becomes public

create_app gives the agent a compiling starter and the rules of the environment. write_files applies the changed text files and runs esbuild on the server.

The response includes compile.ok. If the build fails, it also includes the file, line, column, and compiler message. The agent can use that result for its next edit without opening another terminal or asking me to paste an error back into the conversation.

A failed build is still kept as a version. The preview continues to serve the latest version that compiled successfully.

This is a small detail, but I like what it does to the workflow. A broken edit becomes something the agent can inspect and repair. It does not replace the working preview, and it does not erase the attempt.

Compile is not the same as done

I still open the preview.

A green esbuild result tells me the imports and syntax survived. It does not tell me that the button makes sense, the mobile layout works, or a destructive action is safe.

The preview URL follows the newest successful build:

https://<slug>--preview.drobek.app

Production stays on its current version while the agent keeps editing. When I am happy with a particular compiled version, I ask the agent to publish it.

That final request matters. The Drobek agent instructions say to call publish only when the user asks. The OAuth grant also separates read, write, and publish scopes, so a client does not need deployment access just to inspect an app.

Once published, the app gets its normal address:

https://<slug>.drobek.app

Publishing an older compiled version moves production back to that code. It does not rewind the app's stored data. Preview and production share backend data, so I treat rollback as a code operation, not a database undo button.

I did not give the agent a general-purpose server

The app's JavaScript runs in the browser. Drobek compiles and serves it.

Backend capabilities come from modules installed by the server operator: authentication, data, forms, email, files, and controlled API calls. The agent can use the documented module contracts through skill_info, but it cannot upload arbitrary server code or install a private npm dependency for the app.

That boundary is deliberate. I wanted agents to build small tools quickly without turning every generated frontend into a new server process I now have to trust and operate.

It also keeps secrets out of the generated files. For an external API, the owner enters the credential in the dashboard. The proxy uses it on the server. The browser app and the coding agent do not receive the value.

The part I want to keep human

I am happy to let the agent make several versions, read compiler errors, and improve the preview. Those are fast, reversible steps with visible output.

Making a URL public is different. That is where I want one boring sentence from me: publish this version.

The public core is AGPL-3.0 on GitHub, and the hosted service is available at drobek.app. If you use Claude Code, Codex, Cursor, or Claude to build small browser apps, I would like to know where you draw the publish boundary.

Your AI-built app wants your API key. I built drobek so it never gets it.

Tomas Grasl — Mon, 12 Oct 2026 07:00:00 +0000

The UI is working. Then comes the request: connect an API, save a file, let colleagues sign in. A small vibe-coded app suddenly needs decisions about credentials and access.

I built drobek with a specific boundary: the agent writes the browser app, while backend modules run on the drobek server. A proxy module can attach an API key without putting that key in the generated JavaScript. The agent can configure the connection without receiving the secret value.

An app can start as a useful page and gain backend capabilities as it needs them. I still want to decide what it can reach.

You can see this in a Pokédex, a shared Pixel Wall, and now a game about running the hosting company: Drobek Tycoon.

A Pokédex with no backend of its own

Open the Pokédex and select a Pokémon. The page fetches data from PokéAPI through drobek's proxy module. Its request log makes the calls visible.

The app uses:

import { drobek } from 'drobek';

const response = await drobek.proxy.fetch('pokeapi', '/api/v2/pokemon/25');
if (!response.ok) throw new Error(`PokéAPI request failed: ${response.status}`);
const pokemon = await response.json();

Here, pokeapi names a registered upstream. The server knows its base URL, which methods and paths are allowed, and which apps may call it. The browser sends a request to its own app origin; the proxy checks it and forwards the permitted call.

PokéAPI does not require a key. For an upstream that does, an owner enters the secret in the dashboard and the proxy injects it on the server. MCP tools report whether a secret exists, not its value.

This works for an API-backed dashboard, a weather widget, or a small interface to an existing service. Configure the upstream narrowly enough for that app. A read-only widget usually has no reason to inherit every write endpoint your API exposes.

The proxy also checks destinations against SSRF rules, blocks private and reserved addresses by default, and applies request limits. Those checks matter because “fetch this URL for me” becomes dangerous when the server can reach things the browser cannot. Operators can explicitly allow internal hosts on their own instance; that is an access decision to review.

Keeping a key on the server protects the key itself. It does not make the data returned by the API private. If you permit public callers to read sensitive results, they can still read them.

The basic modules, with jobs for each

These are the built-in pieces an app can use when the operator enables them:

Module	What it does	A small app that needs it
`auth`	App-user sign-in, allowlists, roles and sessions	A tool only colleagues should use
`data`	Stored records with rules for each operation	Saved estimates, requests, or shared task lists
`files`	User uploads, access rules, type checks and quotas	Avatars or attachments
`forms`	Stores submissions and emails the app's owners	A contact form or feedback box
`email`	Notifications to the app's owners	Reporting an item for moderation
`proxy`	Controlled requests to registered APIs, with secrets added server-side	The Pokédex, or an API-backed internal dashboard

The agent can inspect a module through skill_info('<name>'): its SDK types, configuration, limits and examples. It configures an installed module with configure_module. Changes that broaden access can require confirmation in the dashboard.

The app calls the SDK. Access rules are enforced on the server. Hiding a button in React would not protect the corresponding operation.

The modules behind Pixel Wall

Pixel Wall is a shared 64 × 40 canvas. Visitors can look; signed-in people can paint. Each stroke becomes a database record.

Its module-status panel explains the rest of the app: auth handles email-code sign-in, data stores strokes and profiles, and files handles painter avatars. The message form uses forms; reporting a stroke uses email to notify admins.

The visit and stroke counters come from counter, a separate example module. It is not one of the six built-ins. It sits alongside the standard modules and has its own SDK methods.

You can inspect the wall without signing in. Uploading an avatar or painting requires the relevant user action; a module appearing in the panel does not mean every operation has already run.

A game about running drobek

Drobek Tycoon puts you in charge of a small hosting company. You build servers, hire a team, attract customers and handle incidents across three levels. Salaries, power and rent come out of the company budget.

The game keeps your progress in the browser without requiring sign-in. It also has a shared leaderboard for the best company value at each level, and its gallery entry lists the data module. Local game progress and a shared leaderboard serve different purposes; using a backend for one doesn't mean moving the whole game onto the server.

That gives the module model another use beyond forms and internal tools: a browser game with a shared result to compare after a run.

Your company's SSO can fit here too

Suppose your company has its own identity provider and expects internal apps to use it. On your own drobek instance, you can install a module that contributes a sign-in provider through the auth.provider extension point.

The contract has defineAuthProvider, with begin and callback methods. The provider implements and validates the identity-provider exchange. It returns a verified identity; drobek's auth module retains the allowlist, roles, sessions and audit trail. The provider's client secret stays on the server.

That gives you a place to implement company-specific OAuth/OIDC sign-in. It is an extension contract, not a claim that an adapter for every corporate provider ships ready to use. Also, this extension concerns people signing into the hosted apps. Dashboard administrator login is a separate concern.

For a different requirement, such as an ERP operation with custom validation, write a platform module with its own routes and SDK slice. The scaffold starts with:

npm create drobek-module@latest erp

A module can carry configuration, migrations, secrets and documentation for the agent. The operator installs it and selects the modules the instance runs with DROBEK_MODULES. You can also replace a built-in module with your own package implementing the appropriate contract.

The hosted drobek.app service uses the same public core image available to self-hosters. I keep its deployment and service-specific pieces around that core in my separate operations repository, drobek-web. The public module documentation explains the extension mechanisms you can use for your own instance.

Where I put the security boundary

I don't want every small generated app shipping its own server code into the hosting process. In drobek, the server compiles and serves app files; the app's JavaScript runs in the browser. Backend execution belongs to modules chosen by the operator. Apps also have separate origins from the dashboard.

We can maintain and patch these backend modules centrally. When a module needs a fix, its operator updates that module or the core version containing it. Self-hosters control their own update schedule.

Custom modules are trusted server code. They run in the server process with database access, not in an isolated plugin sandbox. Install and review them accordingly. The architecture reduces what an app author can put on the server; it does not turn arbitrary module code into safe code.

For a new app, choose the smallest set of capabilities that does the job. Try the Pokédex to see a proxy request, or the Pixel Wall to see several modules working together. If your backend requirement is more specific, the open-source core and module contract give you somewhere to implement it.

The AI artifact was useful. Then someone wanted to keep using it.

Tomas Grasl — Fri, 09 Oct 2026 07:00:00 +0000

A calculator comes out of an agent session. Someone sends the link to a colleague. The colleague wants to change one assumption, save a scenario, and come back next week.

At that point, there are some ordinary app decisions to make. Where does the current version live? Are changes saved only in this browser? Who can see the saved data? Can you update the calculation without immediately changing the page everyone uses?

drobek gives these small browser apps a place to run.

I previously wrote about using a Claude Artifact as a changing team document. The value in that example was a link colleagues could return to as the work changed. Here I want to look at a browser artifact that needs app behavior: inputs, saved records, and controlled updates.

Keep the first version small

Take a simple planning calculator. It estimates how many working days a task needs from a total number of hours and the hours available each day.

For the example, 24 hours at 6 hours per day is 4 days. Those are illustrative inputs, not measurements from a project. The calculation is small enough to check while we work on the app around it.

The first version can stay entirely in the browser:

function estimateDays(totalHours, hoursPerDay) {
  if (!Number.isFinite(totalHours) || totalHours < 0) {
    throw new Error('Enter a non-negative number of hours.');
  }
  if (!Number.isFinite(hoursPerDay) || hoursPerDay <= 0) {
    throw new Error('Hours per day must be greater than zero.');
  }
  return totalHours / hoursPerDay;
}

That is an arithmetic estimate, not a project forecast. It doesn't model weekends, dependencies, or people getting interrupted. The page should say what the number means instead of displaying it with more confidence than the inputs justify.

If the artifact already has usable HTML or React source, give that source to your coding agent and ask it to adapt the app for drobek. Don't assume an artifact share URL is an import format or that platform-specific features transfer unchanged.

A bounded request helps:

Adapt this calculator's source for drobek.
Preserve the calculation and input validation.
Remove dependencies on the original artifact environment.
Keep all data in the browser for this first version.
Return the preview URL and explain any behavior you changed.

The agent can create the app, write the files, and work from compilation feedback. You still try the actual page. A build can succeed while a text input, error message, or calculation is wrong.

Add persistence when there is something worth saving

If people only need a quick calculation, stop there. A saved-record feature adds access decisions as well as convenience.

For private saved scenarios, one possible design is to add the auth and data modules. A signed-in user creates a scenario and can later retrieve their own records. The data collection rules can be:

{
  "read": "owner|admin",
  "create": "user",
  "update": "owner|admin",
  "delete": "owner|admin"
}

This is the rules object for a configured collection, not the complete module configuration. Here, owner refers to the record owner. admin also has access, so describe that honestly if the interface calls scenarios private.

In the frontend, after the collection and authentication are configured, saving the example could use:

import { drobek } from 'drobek';

await drobek.data.collection('scenarios').create({
  name: 'Example estimate',
  totalHours: 24,
  hoursPerDay: 6
});

Use a schema for the stored fields and validate the inputs on the page too. The data module applies its operation rules on the server. Keeping records out of the rendered list is not access control.

If the next request is shared team scenarios, reconsider those rules. Making every signed-in user a reader is a different product decision from letting each person see their own records. An agent should explain that change before it is confirmed.

Treat updates as versions

Suppose the next change adds a maximum daily capacity or another output. The agent writes a new version, you inspect the preview, and then choose whether to publish it.

The production URL can continue serving the earlier published code while you work. If the new code is wrong, publishing an older version restores that code.

But the app's records are shared between preview and production. A preview test that edits real saved scenarios edits real data. Code rollback doesn't undo those writes. Use a separate app when you need an isolated data experiment.

For images or other binary assets, drobek has a separate asset-upload flow. They do not belong in write_files as a giant base64 string. Review which assets the original artifact depended on and provide replacements where necessary.

A maintained app still needs an owner

Hosting the result doesn't make the model's original analysis correct. If an artifact contains an estimate, a recommendation, or a data-derived conclusion, keep its assumptions and source dates visible. Update the evidence as well as the UI.

And some artifacts should remain documents. If the main job is preserving a decision and its reasoning, a repository or document system may be the better home. The calculator example earns an app because people interact with it and may need persistent state.

In drobek, the agent's edits compile into a preview you can check before changing the production URL colleagues use. You can start with a browser-only tool and add a backend module when a specific need appears. The gallery shows the scale of apps I have in mind, and the core is open source.

Drobek: bring your own AI agent, build an app, then take it outside

Tomas Grasl — Fri, 09 Oct 2026 06:49:02 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

What I Built

I built Drobek, an open-source platform where your own AI agent can create a small web app, give you a preview, and publish it at a URL you can share.

Yes, this is my project. The practical idea is simple: when someone asks an agent for a useful little app, they should be able to keep using it outside the conversation.

My take on Touch Grass is that anyone should be able to make a small website for something happening outside. Organising a walk, a picnic, an outdoor workshop, or an evening of stargazing? Ask your own AI agent for an event page with the meeting point, programme, what to bring, and a registration form. Drobek gives that page a home and a URL you can send to the people coming.

For example, you could start with: "Build a page for our Saturday stargazing meetup. Show the meeting place and programme, add a packing checklist and a signup form, and give me a preview before publishing." That is an example prompt, not a claim that this particular event has already happened. The forms module can store registrations and email the organiser; the app's design and content are yours to change.

The useful part is having a page that fits your event. Make it, share it, then go outside together.

There is already a concrete example running on it: Podzimní obloha, the autumn sky. It has Czech and English text, a Moon phase display, an autumn observing calendar, and a short guide to constellations. It even tells you to grab a blanket and tea and let your eyes adjust to the dark.

You can read what to look for, then put the phone away. That is the sort of app I want people to be able to make their own.

Demo

Open the autumn sky app to try an existing example. It demonstrates what people can publish with Drobek; it predates this challenge week.

The short video below introduces the platform and its agent-to-app workflow. It is an animated product explainer, rather than a recording of a timed build.

You can also browse the app gallery or connect your agent.

Code

The public Drobek repository contains the server, dashboard, MCP interface, SDK, platform modules, and self-hosting documentation. The core is AGPL-3.0. The agent plugins are MIT.

The repository has older history. The main rework I am putting forward here started on October 5; I have kept that history visible. The changelog documents the work, including version-history tools and streaming proxy support on October 5, followed by preview feedback, live data subscriptions, webhooks, and app analytics on October 6.

How I Built It

Drobek is the open-source tooling part of the AI workflow. The agent connects over MCP and calls tools such as create_app, write_files, and publish. The model runs in the agent's environment; Drobek does not bundle a model or require one particular provider.

When the agent writes files, the server compiles them with esbuild and returns compilation errors in the response. The agent can fix the code and try again. A successful build gets a preview URL. I can open it, test it, and decide when to publish that version.

The October work adds more to that loop. People can leave feedback on a preview, and the agent can retrieve and resolve it. It can inspect version history and keep a version for later. Apps can subscribe to data changes, and the proxy supports streaming from configured upstreams.

The app itself runs in the browser. Backend modules provide things like authentication, stored data, forms, files, and API access. Owners enter API secrets in the dashboard, and the proxy uses them server-side. The agent does not need the secret values.

There are deliberate limits: arbitrary app server code and per-app npm install are outside this model. A successful compile still needs a functional check. Preview and production also share the app's backend data, so rolling back code does not roll back records.

Why Does Open Innovation Matter?

The part between an AI-generated app and a usable URL is code you can inspect and run yourself. You can change the platform, add a backend module, or host it on your own server with Postgres, Redis, and Caddy.

MCP gives the agent a documented interface to that platform. The build loop and deployment do not depend on a hidden conversation inside one app builder. The choice of agent and model stays with the person building the app, including whether they use an open-source agent setup.

Self-hosting also gives you control over where the platform stores app data. The connected agent and its model provider have their own data handling and costs; choosing your own host does not make those disappear.

For this submission, the open contribution is Drobek itself: the infrastructure people can use to turn an idea into their own small app. Try the autumn sky example, and the source and self-hosting instructions are there if you want to build on it.

Don't blame AI before you check your architecture

Tomas Grasl — Wed, 07 Oct 2026 19:18:43 +0000

Give an AI coding agent a small task: add voucher activation to an existing subscription system.

The generated code might look reasonable. The endpoint works, the response is correct, and the happy-path test passes. But the voucher rules now live in a controller, next to a database query and a call to a payment provider.

Was the model bad? Maybe. I would also look at the examples the repository gave it.

If similar rules already live in controllers, services and persistence callbacks, “follow the existing architecture” leaves quite a lot open to interpretation. A human joining that project would have questions too.

This is where I think architecture deserves more attention in AI-assisted development. The structure of a project supplies context for the next change. Clear responsibilities make that change easier to describe and its mistakes easier to detect.

PHP and Symfony make a useful example here. PHP sometimes gets dismissed before the discussion even starts, but typed interfaces, dependency injection and static analysis give us plenty to work with.

One feature, several places to put it

Consider an illustrative subscription application. Customers can already buy a subscription through a payment provider. Now we want this feature:

Allow a customer to activate a subscription with a voucher.

That sentence leaves business decisions open. Does the voucher cover a particular plan? Can it be redeemed more than once? What happens if the customer already has an active subscription?

For this example, let's choose explicit rules: a voucher activates one eligible subscription, expires at a defined time, and can be redeemed once. An already-active subscription must be rejected. Voucher activation must not charge the customer.

These are invented requirements for the example, not a report from a production system.

Suppose the relevant code looks like this:

src/
  Controller/SubscriptionController.php
  Service/SubscriptionManager.php
  Service/PaymentHelper.php
  Entity/Subscription.php
  Repository/SubscriptionRepository.php

There is nothing inherently wrong with these directories. The difficulty starts when responsibilities overlap: the controller checks eligibility, the manager changes status, and the payment helper also persists subscriptions.

Now an agent has several plausible places to add voucher validation. Reading more files may reveal the intended convention. It may also reveal three incompatible conventions.

The prompt can explain the desired design, but that explanation is doing work the codebase could help with.

Give the change a clear home

For an application with enough business logic to justify it, I would consider a structure like this:

src/Subscription/
  Domain/
    Subscription.php
    Voucher.php
    SubscriptionRepository.php
    VoucherRepository.php
  Application/
    CreateSubscription.php
    ActivateSubscriptionWithVoucher.php
  Infrastructure/
    DoctrineSubscriptionRepository.php
    DoctrineVoucherRepository.php
    StripePaymentGateway.php
  UI/
    Http/ActivateSubscriptionWithVoucherController.php

The application use case coordinates activation. Domain objects or a domain policy enforce the business rules. Repository interfaces describe the persistence operations those rules and use cases need. Doctrine implements them at the edge.

The HTTP controller handles the request, invokes the use case and maps the result to a response. It should not become a second implementation of voucher eligibility.

This follows the separation behind Alistair Cockburn's hexagonal architecture: the application communicates with external systems through ports and adapters. The folder names are our choice; the useful property is that business behavior can be exercised independently of the HTTP and database adapters.

For our example, the intended source-code dependencies are:

UI ------------> Application ------------> Domain
Infrastructure -------------------------> Domain

The infrastructure classes implement interfaces defined inward. The application's wiring connects those interfaces to concrete adapters.

At runtime, a use case can call a Doctrine-backed repository through an interface. Its source code still does not need to import Doctrine.

Symfony's autowiring and interface aliases support this wiring. A constructor can request an interface while the container supplies the configured implementation. Symfony does not choose the business boundaries for us.

An agent working on voucher activation now has a named use case to inspect and a dependency rule to follow. Reviewers can ask precise questions: why did this patch add an HTTP dependency to the domain? Why is a payment gateway involved in a feature that must not charge anyone?

The names need to mean something

DDD is useful here because of the shared language it asks us to establish.

In this example, a voucher redeems an entitlement. A payment records a financial transaction. Both may lead to an active subscription, but they have different rules. Calling both operations process() hides a distinction the implementation needs to preserve.

Names such as ActivateSubscriptionWithVoucher put that distinction where both a developer and an agent will encounter it. CommonService gives them less to work with.

The names still need definitions. If “customer” means an account in one module and a billing contact in another, a consistent-looking class name can conceal a mismatch. A short glossary and examples of the intended behavior are useful companions to the code.

My expectation is that this reduces the decisions an agent has to infer. I am not claiming a measured improvement in model accuracy from renaming classes or introducing DDD.

Make violations visible

A directory named Domain cannot stop someone importing an HTTP client into it.

Deptrac can check PHP dependencies against configured layers and allowed relationships, including in CI. For the structure above, I would forbid domain dependencies on application, infrastructure and UI code, and reject application imports from infrastructure or UI.

The configuration needs to cover the relevant namespaces and external packages. Unclassified code can leave gaps. A green architecture check only proves that the dependencies it analyzed satisfy the rules we configured.

Behavior requires separate tests. For voucher activation, I would want tests showing that an expired voucher fails, an eligible voucher activates the subscription, and repeated redemption does not grant another entitlement. The application test should also verify that the payment gateway is not called.

There is a persistence problem hiding in that last requirement. Two requests can read the same unused voucher before either writes its result. A domain method that checks isRedeemed() cannot prevent that race by itself.

The persistence implementation needs an appropriate atomic update or locking strategy, with subscription activation and redemption committed consistently. I would include an integration test for competing redemption attempts. Neat layers do not settle transaction semantics.

These checks give the agent concrete feedback during a change. A developer still needs to decide whether the tests express the right behavior and inspect changes to the checks themselves. An agent that “fixes” a failing dependency rule by weakening it has changed the architecture contract.

Keep repository instructions short and connected to code

An AGENTS.md or CLAUDE.md file can tell an agent where to begin. For this example, useful instructions would point to the subscription module, explain the dependency direction and identify the commands for running its checks.

I would also include the rule that voucher activation never charges a customer, with a link to the test that verifies it. That is much more actionable than “always write clean code.”

Then I would ask the agent to inspect the existing activation path and propose the files it expects to change before editing. Its plan should account for the use case, domain rules, persistence behavior and tests. If it proposes putting the whole feature in the controller, there is something concrete to discuss before the patch grows.

Research gives a useful, narrower reference point here. Microsoft's CodePlan paper treats repository-level coding as a planning problem and combines dependency analysis with analysis of how changes affect other code. Its evaluation covers C# package migrations and Python edits. It is not evidence that hexagonal PHP applications automatically produce better AI results.

My practical inference is that dependencies deserve to be explicit enough to inspect and validate. The article's voucher example illustrates that idea; it is not a benchmark.

Start with the boundary that keeps breaking

I would not introduce this entire structure into a small CRUD application just to accommodate an AI agent. Every additional interface and layer creates work for the people maintaining it.

For an existing project, start with one recurring problem. If controllers keep acquiring subscription rules, move one coherent use case behind a clear entry point. Name its business concepts, add tests for the rules, and enforce the dependency boundary that matters.

Try the next related change with the agent. Look at whether its patch uses that entry point, whether the tests catch the mistakes you care about, and how much explanation the review still needs. Expand the structure only when it earns its place.

A better model or a clearer prompt may help. I would also check what the repository is teaching it: where behavior belongs, which dependencies are allowed, and how a wrong change gets rejected.

For the voucher feature, success means the business rules have one clear home, redemption is safe under competing requests, and the next developer can find all of it. That remains our responsibility when an agent writes the patch.

Your own agent, your own server: self-hosting drobek

Tomas Grasl — Wed, 07 Oct 2026 07:00:00 +0000

The useful part of self-hosting drobek is deciding where those small AI-built apps live. Your colleagues can keep using their own coding agents. You run the place that compiles the frontend, serves it, and provides the backend modules.

You also take responsibility for the server, email delivery, backups, and updates. The setup below uses the v0.5.0 deployment files.

The stack is one drobek image plus Postgres, Redis, and Caddy. Caddy handles HTTPS. Only Caddy exposes public ports in the production Compose setup; the app server and databases stay on the internal network.

Start with DNS and email

For this release's prebuilt image, use a Linux amd64 server. Have Docker Engine, Compose v2, Git, OpenSSL, and Task v3 available. The repository's self-hosting guide includes installation steps for a clean Ubuntu 24.04 host.

Check the tools before proceeding:

docker compose version
task --version

You need ports 80 and 443 reachable and two DNS records pointing at the server:

Record	Example
Dashboard A/AAAA	`drobek.example.com`
Wildcard app A/AAAA	`*.apps.example.net`

Replace the example domains with domains you control. The separate registrable domain for apps is deliberate: those apps contain code generated for their owners and should be separated from the dashboard.

You also need working email delivery. This walkthrough uses SMTP. drobek sends sign-in codes by email, so a healthy web process with broken SMTP still leaves you unable to complete that login flow.

Get matching deployment files and image

On a new server, in a directory you can manage:

git clone --branch v0.5.0 --depth 1 \
  https://github.com/freema/drobek.git drobek
cd drobek

Pinning the checkout and image to the same release makes the setup easier to reason about. These commands use v0.5.0; check the release notes before selecting a newer version.

Initialize the configuration with your real hosts and email settings:

DOMAIN=drobek.example.com \
APPS_DOMAIN=apps.example.net \
DROBEK_IMAGE_TAG=v0.5.0 \
TLS_ACME_EMAIL=you@example.com \
SUPERADMIN_EMAIL=you@example.com \
SMTP_HOST=smtp.example.com \
SMTP_PORT=587 \
SMTP_USER=no-reply@example.com \
EMAIL_FROM=no-reply@example.com \
task selfhost:init

The initializer generates secrets, writes .env.production with mode 600, and renders the Caddy configuration. It can run again without replacing existing secrets.

Edit .env.production to supply SMTP_PASS. Keep the password out of a pasted shell command and out of Git. Follow the file's quoting instructions if a value contains characters such as $, #, or spaces.

Decide who can publish

Before sharing the instance, choose who may publish. The default publishing mode is open. If this is a server where workspaces should need operator approval before publishing, set these values in .env.production before starting it:

PUBLISH_APPROVAL=approval
OPERATOR_EMAIL=you@example.com

This controls publishing. It does not turn registration off or block creation and previewing of apps. Existing live content also isn't removed just because a workspace is later blocked from publishing.

The publishing policy documentation explains the separate workspace states and takedown controls. Choose the behavior that matches how you intend to run the instance.

Bring the stack up

docker compose --env-file .env.production \
  -f docker-compose.production.yaml up -d --wait

The first start pulls the images and applies database migrations. Check the dashboard endpoints using your actual hostname:

curl -fsS https://drobek.example.com/healthz
curl -fsS https://drobek.example.com/api/version

The health response should report the database and Redis as up. The version endpoint lets you check which image is serving requests. These are expected checks, not output from your server until you run them.

With a real domain, the default TLS mode issues app certificates on demand through Caddy. The first request to a new app hostname can take longer while its certificate is issued. Both the DNS wildcard and reachable validation ports matter here.

Open the dashboard, sign in using SUPERADMIN_EMAIL, and enter the code sent by email.

Connect an agent and build something small

For Claude Code, the documented connection is:

claude mcp add --transport http drobek \
  https://drobek.example.com/mcp

Complete its OAuth flow. To make an app live, the connection needs the publishing scope as well as the relevant workspace permission.

For a first app, keep the request easy to inspect:

Build a tip calculator on drobek.
Use a bill amount, tip percentage, and number of people.
Handle zero people and invalid amounts without dividing by zero.
Give me the preview URL before publishing.

Open the preview and try the edge cases. Ask the agent to publish only once the result behaves as expected. The returned production URL belongs to the chosen published version; later edits can stay in preview.

This is frontend hosting with platform modules. It doesn't mean the agent now has permission to deploy arbitrary server code to your machine.

Back up the keys as well as the data

From the checkout, the supported backup task is:

task backup

It creates an archive containing the database and the relevant file, asset, module, and Caddy data. Copy the archives off the host.

.env.production is not in that archive. Keep a protected copy separately. In particular, the master key is needed to decrypt restored upstream secrets. A database backup without the corresponding key isn't a complete recovery plan.

Redis is not backed up by this task, so users sign in again after a restore on a fresh machine. The backup runs online; if you need a quiesced snapshot across database and file operations, follow the guide's instructions for stopping writes.

Rehearse restoring to a separate empty stack before depending on the backups. The restore procedure checks the archive and key and normally refuses a non-empty database.

Keep upgrades deliberate

For an update, read the target release notes, move the deployment checkout to that tag, and set the matching DROBEK_IMAGE_TAG in .env.production. Then use:

task selfhost:upgrade

The task takes a backup and runs migrations before bringing the updated application up. An app-code rollback and a server/database rollback are different operations; don't assume an older server image can understand a newer database schema.

Once the first app is live, keep checking email delivery and backup recovery. Review access as people join, and keep the server updated. The repository contains the deployment files and the full guide when you need custom domains, other TLS modes, or external modules.

Stop prompting from scratch. Copy a drobek app and change the useful part.

Tomas Grasl — Mon, 05 Oct 2026 07:00:00 +0000

You find a small app that does almost what you need. The layout works. The interaction makes sense. You want a different calculation, a few extra fields, or your own version for your team.

Starting with another blank prompt feels wasteful. There is already a working example to build from.

drobek lets an owner make a published gallery app duplicable. Someone else can then copy it into their own workspace and ask their agent to change it. The copy gets its own identity and version history.

The copy starts with the published files. You do not inherit the original owner's users, records, or API keys.

The owner chooses whether an app can be copied

A public URL alone doesn't make an app duplicable.

The server must have its gallery enabled. The owner lists a published app and turns on Allow duplicates. The app must remain eligible for the public gallery; a private or removed listing isn't a back door to its source.

In the dashboard, the Gallery section on the app's Overview page holds those choices. An agent can also use set_gallery_listing, but listing the app and allowing copies require the user's explicit confirmation.

The gallery entry then supplies a duplicate URL. A visitor signs in, chooses a workspace where they can edit apps, and gives the copy a name.

Version one is the published app

The new app starts unpublished, with the source app's published files as version 1. It does not take the author's newer preview edits.

The person making a copy starts from what they saw running, while the original author can keep unfinished changes in preview.

The copy remembers its source through duplicated_from. It is still a separate app. The copy operation does not establish a Git remote, a branch, or an automatic stream of updates from the original.

Through MCP, the tool is duplicate_app. For a gallery app with the example slug pixel-wall, the arguments look like this:

{
  "from": "pixel-wall",
  "name": "My pixel wall"
}

Use the slug or URL of a real, duplicable app on the server your agent is connected to. This is an example call shape, not a promise that a particular gallery entry is available. The tool does not import apps from another drobek server by URL.

What transfers, and what needs attention

Item	Behavior
Published source and build output	Become version 1 of the new app.
Newer preview edits	Stay with the original app.
Saved module settings	Proposed through the copy's configuration flow, after filtering.
Settings that need confirmation	Wait on the copy's Modules page.
Email addresses in configuration	Removed.
Proxy configuration and upstream assignments	Not copied.
Secret values, records, end users, uploaded files	Not copied.
Uploaded app assets, domains, gallery listing	Not copied.

An image uploaded as an app asset won't appear in the copy. A frontend that calls a named proxy upstream needs a suitable upstream configured for its new workspace. The original owner's external service is not yours to use.

The tool response separates module settings into applied, pending, and skipped. An agent should inspect all three. “The copy exists” does not mean “every integration is ready.”

These rules are in the agent contract and the copy configuration implementation.

Give the agent a small change

For a first attempt, I would choose a simple app without private integrations. Then give the agent a bounded request:

Duplicate this gallery app into my personal workspace.
Rename the copy and change its heading and color palette.
Keep the existing interaction working.

Inspect applied, pending, and skipped module settings.
Tell me which configuration or assets need replacing.
Give me the preview URL before publishing.

You can then change the useful part: the calculation, the workflow, or the fields. Test the copy with its own data. If it needs an external API, register the upstream in your workspace and supply your own credentials through the dashboard.

When the result works, publish the copy. It gets its own production URL. Listing that copy in the gallery is another deliberate choice.

This fits small tools that already do most of what you need. You can inspect a working starting point, make the change you actually need, and keep your own version. Browse the gallery for apps whose owners have enabled duplication, or read the source.

Your OSINT agent found a connection. Now try to prove it wrong.

Tomas Grasl — Fri, 02 Oct 2026 07:00:00 +0000

Give an agent a suspicious domain and it can come back with a convincing story. Several websites share infrastructure. Their pages look similar. A timeline seems to line up.

You still need to know which parts are observations and which parts are the agent joining the dots.

I've also worked on analysing Facebook scam ads. That experience is why I care about the distinction between a lead worth following and a connection I can defend.

Ads impersonating bankers and central-bank governors make a useful example. For a cross-country investigation, the scope could cover ten large European countries and include inactive campaigns. That is a scope to define and check, not a result in itself.

The workflow starts with a suspicion. Choose a test, inspect the result, and use it to decide what to ask next. That also includes dropping a suspicion when the evidence doesn't support it.

Make the question small enough to fail

“Find out everything about this network” is a reasonable opening request. It is a poor definition of done.

For the advertising example, I would first make the scope explicit. Which countries, selected by which measure? What time window? What counts as impersonation? Which sources can actually show inactive ads, and which cannot?

Those decisions affect what a missing result means. “We found no matching ads in this source during this period” is a much narrower claim than “this campaign never ran in that country.”

Then separate candidate explanations. Similar pages might belong to the same operator. They might also use the same template, hosting service, or copied creative. A shared IP is an observation to investigate, not a person's identity.

A prompt I would use at that point:

For each proposed connection, record:
- the exact observation and its source;
- when the observation was captured;
- the explanation it supports;
- a plausible alternative explanation;
- the next check that could weaken the connection.

Keep unsupported connections as hypotheses.

This prompt sets up the investigation. It does not establish what the evidence will show.

Knowing the tools still matters

An agent that can use tools saves a lot of switching between tabs. It still benefits from someone who knows which tool answers which question.

For example, urlscan's API can search existing scans by attributes including domains and IPs, and retrieve scan results. Searching existing material and submitting a new scan are different actions. A submission has a visibility setting; “unlisted” is not the same as private. I would check existing scans first and decide separately whether a new submission is appropriate.

The same care applies to interpreting the result. A scan is an observation from a particular run. It doesn't establish everything a site has ever served or who ultimately controls it.

The human contribution is often choosing a better test. If the question concerns writing style, another infrastructure lookup may add little. Comparing text may be worth exploring, while remembering that shared templates, translation, or editing can also explain similarities. A similarity score is not authorship proof.

Save evidence the next run can inspect

A long chat is an awkward place to maintain a case. I would keep a small working directory alongside it:

case/
  scope.md
  hypotheses.md
  evidence.csv
  sources/
  runs/
    2026-10-02.md

An evidence row can hold a source URL, capture time, saved file, observation, and the hypothesis it relates to. Keep the original material available. A summary that says “three domains were connected” is hard to audit if the actual relationship has disappeared into an earlier conversation.

A run note should record what was checked, what changed, what contradicted the current explanation, and what remains unknown. The next run can then compare new evidence with a named previous state.

I would also record which actions the agent may take. Reading public sources is different from contacting people or submitting information to another service. If an agent proposes sending an email, the person running the investigation needs to decide whether that contact is appropriate. Tool access alone isn't permission to make contact.

Repeating a run doesn't validate its conclusion

Forecasting raises the same questions about repeated assessments and memory. Keeping instructions in a file lets the next run assess new evidence against the same question.

For a forecast, I would define the event, deadline, and resolution criteria before the next run. Save the previous probability and its reasons. Then ask which new observations justify changing it.

Otherwise, you can end up with a fresh, confident paragraph each morning and no way to tell whether the forecasting process is improving. A forecast needs outcomes to compare against. Repetition alone doesn't supply them.

The same applies to an investigation. A later run that repeats an earlier unsupported claim has not found independent corroboration.

A useful result can be “the suspicion got weaker”

I want an OSINT agent to help me examine more possibilities while keeping the evidence behind each connection easy to inspect.

I would rather finish with a narrower claim I can defend than a large network diagram whose edges mean five different things. Before sharing a conclusion, I want to be able to open the source behind each material claim and explain what would change my mind.

Your agent wrote the app. Here's what drobek actually runs.

Tomas Grasl — Wed, 30 Sep 2026 07:00:00 +0000

An agent can produce a working React app and a very optimistic explanation of why it is ready for production. I still want to know where its code will run, what it can access, and what happens when the next edit breaks the build.

Those questions shaped drobek. I introduced it here: a place to host small apps built by your own coding agent. The build and deployment flow is worth a closer look.

drobek compiles and serves the app's frontend. The app's JavaScript runs in the browser. Backend work goes through platform modules installed by the server operator.

A write includes the build result

The agent connects over MCP and calls create_app. It gets a starter, an app ID, a preview URL, and a briefing describing the environment. It can ask skill_info for the current module contracts instead of guessing an SDK from an old example.

The next step is write_files. The call contains changed text files and a short reason for the edit. drobek applies those changes to the latest version and compiles the result in-process with esbuild.

The response includes compile.ok and compiler errors with file, line, column, and message. The agent can make its next correction from that response. It doesn't need a separate terminal session to discover that an import failed.

A failed compile is still stored as a version. The preview keeps serving the last version that compiled successfully. The broken source isn't lost, and the agent can fix it with another write.

This is the documented flow, rather than a transcript from a particular run:

create_app
    -> app ID, starter, briefing, preview URL
write_files
    -> numbered version, compile result
    -> on failure: fix the source and write again
    -> on success: inspect the preview
publish
    -> chosen compiled version becomes production

The agent contract describes the tools and their return values.

Preview and production have different jobs

App hosts look like this:

<slug>.<APPS_DOMAIN>             production
<slug>--preview.<APPS_DOMAIN>    latest successful build
<slug>--v<N>.<APPS_DOMAIN>       a specific version

Publishing moves a pointer to a compiled version. Publishing an older version rolls production back. restore_version does something slightly different: it creates a new working version from older files. It doesn't rewrite history or publish that result automatically.

I want that distinction to stay visible. An agent can keep editing while the production URL serves the version people have already checked.

But preview is not an isolated staging environment. Preview and production share the app's backend data. If you test a delete operation in preview, changing the production code pointer later will not bring the record back. Use separate test data or a separate app for that kind of experiment.

Backend behavior comes from modules

The built-in modules cover authentication, records, forms, email, files, and API proxying. The frontend imports the browser SDK:

import { drobek } from 'drobek';

const todos = await drobek.data.collection('todos').list();

That import resolves to drobek's SDK. You don't install a separate package into each hosted app.

The collection's server-side configuration controls access. For example, this configuration lets signed-in users create records, then read and modify their own records. App admins can work across those records:

{
  "collections": {
    "todos": {
      "rules": {
        "read": "owner|admin",
        "create": "user",
        "update": "owner|admin",
        "delete": "owner|admin"
      }
    }
  }
}

Here, owner means the record's owner. It does not mean every person who can edit the app in the dashboard. App-user authentication and dashboard workspace roles are separate concerns.

The module checks these rules when a request reaches the backend. A frontend that forgets to hide a button doesn't grant permission. Broader access changes can require owner confirmation through the dashboard. The module documentation lists those cases.

Keys don't belong in the agent's output

For an external API, the workspace administrator registers an upstream. Its secret goes into the dashboard, and the proxy uses it server-side. MCP can report whether a secret is present without returning its value.

Each app also has its own origin, separate from the dashboard. These are useful boundaries, but they don't make an arbitrary generated frontend trustworthy. It can still have bugs, render misleading information, or make requests allowed by an overly broad configuration.

The modules themselves are trusted server code. Installing a third-party module is an operator decision, not something an app's agent can do by writing frontend files.

What this leaves out

drobek isn't intended for arbitrary server applications, per-app background workers, or a private dependency installation for every app. If your app needs those, this hosting model may not fit.

For the smaller tools my colleagues build, I want a workflow where the agent gets useful build feedback, the person gets a preview, and publishing selects a version we have actually looked at. You can inspect the implementation in the architecture guide and source.

I wanted vibe-coded apps, not another AI credit bill. So I built drobek.

Tomas Grasl — Mon, 28 Sep 2026 07:49:21 +0000

Vibe coding is everywhere. So are the credit meters.

Ever read the spending threads on r/lovable? This one has people burning through hundreds of credits while still trying to get their apps working. Other people are happy with what they shipped. But the question stuck with me: if I already have a coding agent, why do I need another platform's AI credits?

Lovable bundles building and cloud services into its platform. I wanted to keep using my own agent and have somewhere to deploy the result.

So I built drobek, an open-source hosting platform for small web apps. Bring Claude Code, Cursor, or Codex, connect over MCP, and publish what you build. drobek doesn't sell you AI tokens. Your model usage stays with your agent's provider. Hosting still costs money, whether you use a hosted service or run your own server.

The source is on GitHub, under AGPL-3.0. There is a hosted version at drobek.app, and you can self-host it.

At work, almost everyone vibecodes now. People build landing pages, internal tools, and reports for colleagues. The next question is usually where to put them, who gets access, and what to do with the API keys. That's the part I wanted drobek to handle.

The agent connects to drobek over MCP, creates an app, and sends the source files. drobek compiles them and returns errors the agent can fix. A successful build gets a preview URL. You try it, ask for changes, and publish when you're ready. Each successful build is a numbered version, so you can also publish an older one.

The app's JavaScript runs in the browser. drobek compiles and serves it; it doesn't execute agent-written application code on the server. Backend features come from platform modules: login, data storage, forms, file uploads, owner notifications, and API proxying.

That gives me a clearer security boundary for these small apps. Each app has its own origin. Owners enter API secrets in the dashboard, and the relevant module uses them on the server. The agent doesn't need the secret values. Data access rules belong in the backend module, where hiding a button in the frontend can't bypass them. You still need to configure those rules and review what you publish.

Here's a small example from the public gallery: a Pokédex with search, stats, and a live log of requests through drobek's proxy module. PokéAPI is public, so this demo doesn't need a secret API key.

This is the size of app I have in mind: something useful enough to share, without maintaining a custom backend for every little tool. drobek targets browser apps; it isn't a place to run arbitrary server code or background workers. Also, preview and production share an app's backend data. Rolling back the code doesn't roll back the database.

I'll follow up with the technical details, copying and sharing apps, self-hosting, and turning an artifact into something people can keep using. For now, browse the gallery or have a look at the repo.

Where do the little apps your colleagues vibe code end up today?

Anthropic deleted 80% of Claude Code's system prompt. Here is what I changed in my setup.

Tomas Grasl — Mon, 07 Sep 2026 07:14:16 +0000

Are you burning tokens in Claude Code and getting worse results than you should? Your old habits might be the reason.

Anthropic removed over 80% of Claude Code's system prompt. No measurable loss on their coding evals. Thariq Shihipar from Anthropic wrote it up on July 24 in "The new rules of context engineering for Claude 5 generation models". It was not quiet at all, most people just missed it.

The number is not the interesting part. The reason is. Those instructions were there to keep weaker models in line. On Opus 5 and Fable 5 they only get in the way. The model burns tokens figuring out which of your contradicting rules wins, and only then touches the code.

Eight things I would rethink in my workflow after reading it.

1. Role-play prompting is over

"You are a senior developer with 20 years of experience" does nothing. Neither does "focus 100%". The model does not need it.

What works better:

Context and goal. Say what you are working on and who it is for, not just what you want generated.
Show, do not describe. Instead of "write informally", point at a real reference file with @.
Measurable scope. "Max 5 sentences" beats "do not be too long".

2. Switching models mid-session

Claude Code sends the whole history with every request. Caching is what saves you: it is a prefix cache with an exact match from the start of the request, so the already processed part costs a fraction.

The mistake: switching from Opus to Sonnet to save money.

What actually happens: each model has its own cache. The next request reads the entire history with zero cache hits. Same for changing effort level, with one exception, Fable 5.1 on an API key or a subscription keeps the cache.

And here is the part almost nobody mentions. If you genuinely need more than one model, do not switch. Hang them off as subagents or a workflow. A subagent starts its own conversation with its own cache, and from the parent side only the call and the result get appended, so the parent prefix stays intact. In a workflow fan-out Claude Code goes further and holds same-prefix agents for a few seconds so the first one can warm the cache and the rest read from it.

3. Prohibitions confuse the model

Flood it with a list of things it must not do and every rule has to be reconciled against the others. Anthropic describes this on their own prompt: one line said leave documentation where appropriate, another said DO NOT ADD COMMENTS, and the model spent reasoning on that before it touched a file.

Fix: "answer in max 5 sentences" instead of "do not write long answers". "Write in full sentences" instead of "do not use bullets".

4. Hard rules belong in hooks

CLAUDE.md (not .claudemd, that file does not exist) is context for Claude, not enforced configuration. The docs say it plainly: if you want to block an action regardless of what the model decides, that is a PreToolUse hook.

A hook is a plain deterministic script Claude Code runs at a given lifecycle event. It can check encoding of non-ASCII characters or kill an attempt to read credentials. You create one by asking Claude for it in the terminal.

One gotcha: editing CLAUDE.md mid-task does not apply. Claude keeps working with the version loaded at session start. The new content loads on the next /clear, /compact or restart.

5. Infinite exploration

A vague task in a big repo means Claude starts opening files blind. Every file it reads lands in the context window in full. You are not just burning tokens, you are filling context with noise. Navigate it to the exact place where the answer lives.

6. Effort level

There is no slider in the corner of the window, Claude Code is a terminal. Effort is set in config or in session, and the levels are low, medium, high, xhigh and max. Default is high. ("Ultra Code", which floats around on blogs, is not an official level.)

The mistake is running max on ordinary tasks. Anthropic says themselves that max is for genuinely frontier problems and that on most workloads it mainly adds cost, and on structured output it can lead to overthinking. And since every effort level has its own cache, changing it mid-session costs you a recompute of the whole history.

7. A full context window is not free

A million tokens fits. That is not the same as the model recalling what it needs from them. Anthropic published MRCR v2 numbers with Opus 4.6: 93% at 256K tokens, 76% at 1M.

Careful with the reading though. MRCR measures retrieval of a planted fact, not instruction following. Still a clear signal: reliability drops long before you run out of window. After a finished subtask run /clear, at a natural break /compact, and on long work have it write a handoff to a file and start a fresh session.

8. Regular hygiene

You do not have to guess what to cut from CLAUDE.md. Claude Code has /doctor and it proposes the trims for you. It cuts what Claude can derive from the repo (directory layout, dependency lists, architecture overview) and keeps what it cannot (gotchas, generated files, the non-obvious build step).

And check your auto memory. It lives in ~/.claude/projects/<project>/memory/. Each session loads the first 200 lines or 25 KB of MEMORY.md, and topic files are read on demand. Browse it with /memory, and /context shows what actually loaded into the current session. When Claude behaves strangely and you do not know why, it is usually a contradicting note sitting right there.

The summary

Coding with AI in 2026 is not about who writes the longer system prompt. It is context management, deterministic verification through hooks, and cleaning history as you go.

How do you handle context limits? Hooks already, or still a giant CLAUDE.md?

Same skeleton, different last gate: reading Anthropic's commerce-agents with my own agent open in the other window

Tomas Grasl — Thu, 03 Sep 2026 19:50:12 +0000

Anthropic shipped commerce-agents: a reference shopping agent and merchant agent, three runtime paths, a Claude Code plugin.

I do not build e-shops. I have an agent over Jira, GitLab, Sentry, mail and around 120 repositories. It writes analyses into Jira, reviews merge requests, checks mailer templates, audits worklogs. Code is the smaller part of the job.

I read their repo for a full day and kept thinking: I have this too. Just as a sentence in a markdown file.

The skeleton is the same. What is not the same is who stands at the end of the chain, and that one question decides how much of your agent is prose and how much of it is code.

Four layers, both sides

Strip the domain away and both repos are the same four layers:

Policy: who the agent is, what it must never do.
Capabilities: what it can call.
Procedures: how repeated work gets done.
Knowledge and state: what it knows about the domain, and where the work currently stands.

In my repo that maps to CLAUDE.md (8 hard rules), a folder of commands, a few local skills plus plugins from an internal marketplace, and docs/ plus tasks/. There is not a single line of production code in it. Production code lives in the 120 repos. This one is the cockpit.

In theirs it maps to the agent prompt, tool definitions, flows and the vertical knowledge packs. Retail, travel, telecom, ticketing.

Different domain, same shape. That part was easy to accept.

The difference: who is the last gate

At my keyboard, I am the last gate. Before the agent writes anything into Jira or posts a review comment, it shows me the draft and waits. Before anything gets deployed, it runs into the fact that I am the one who clicks.

Their agent talks to a customer who has never heard of Claude Code. Nobody sits in between.

That is the whole difference, and everything else follows from it. Every rule I keep as a sentence in CLAUDE.md, they have as code:

Provenance gate. The agent can only write against an ID it actually read in this session. Not one it remembers from an earlier run, and definitely not one that appeared inside some text it was given. Product descriptions, reviews, customer mail: all of that is input, and input can contain instructions that look exactly like yours.

Staged change. The model never applies anything. It proposes, a human commits. The interesting part is that this is not a permission check somewhere in the flow, it is the shape of the API: there is no code path where the model's output goes straight through.

Fencing untrusted text. Every piece of foreign content gets wrapped so it cannot be read as instruction. Boring, mechanical, and the thing everyone skips because "the model is smart enough".

Tests that run against prompt bytes, not against the model. This is the one that took me longest to appreciate. They are not testing whether the model behaves correctly. They are testing that the assembled prompt does not contain what it should not contain. Deterministic, no model in the loop, runs in CI in milliseconds.

One line from their docs is the most useful thing I read in a month: a rule in the prompt is one injection or one bad sample away from being skipped.

I have that verified from the other side.

Three weeks of prose quietly leaking

Because a human sits at my keyboard, prose felt like enough. For three weeks my advisory rules leaked, in small ways I only saw when I went looking:

The rule says "when I say go, it is go". The agent asked a second time anyway, after I had already approved a draft. That is not caution, that is a stall.
The rule says every status transition gets a worklog and every note gets a ticket link. Some notes went in without links.
The rule says short messages. Long status walls kept coming.

None of these is dramatic on its own. Together they are the same failure mode the Anthropic docs describe, just without an attacker: a sentence in a prompt is a suggestion the model is free to deprioritize when the context gets long.

So I ported two things the same day.

A hook instead of a sentence. Writing to Jira now goes through a hook that only lets the call through if the issue key was read in this session, and always via a dialog I click. Same rule as before, except now it is not a rule, it is the only available path.

Roughly, in pseudo-code:

// simplified: the real one lives in a Claude Code hook
export function beforeJiraWrite(call: ToolCall, session: SessionLog) {
  const key = call.input.issueKey;

  if (!session.readIssueKeys.has(key)) {
    return deny(`${key} was not read in this session. Fetch it first.`);
  }

  return askUser(`Write to ${key}?`, call); // no silent path exists
}

A check script for my own text. Commands validated against the README, the team roster against the people files, regexes for secrets, in-progress tasks without a ticket link. First run: 26 findings. I had spent three weeks writing rules about verification and had never once verified my own repo.

Where the two designs diverge, and why

The differences are not about anyone being smarter. They fall out of a single constraint: their agent talks to a stranger, mine talks to me.

	commerce-agents	my cockpit
Gates	hooks and CI tests	confirmation before every write
Learning	evals	one dated line with a ticket number per failure
Verification	evals written by the same agent that wrote the flow	e2e verifier gets only acceptance criteria and a URL, never the diff
Subagents	avoided, latency matters in a chat	used for heavy reads, waiting is fine, context bloat is not

Their "skills over subagents" advice is correct for a customer chat where every second is visible. In a cockpit I do not care if a check takes 40 seconds. I care that a worklog dump is 30k tokens and has no business being in the main session.

The learning mechanism is the one I am keeping as it is. Every failure ends up as one line with a date and a ticket number in docs/conventions.md. Two real ones, so this is not abstract:

A deploy tag shaped like a number with a dot is a valid YAML float. The ConfigMap rejected it and production went down. That is now a documented trap with a fix pattern that every other repo points at.
A monthly worklog check reported 45 hours missing. Reality was 19. The cause: the MCP endpoint returns at most 20 worklogs per issue and does not paginate. The lesson line now says where totals may come from and where they may not.

The repo learns, the model does not. That is the entire mechanism, and it costs one line per screw-up.

The part worth taking

The interesting question about agents is not whether the model can write the code. It can, and that debate is boring now.

The interesting question is where the gates stand and who is last in the chain. Anthropic had to answer it in code because nobody sits between their agent and a stranger. I assumed prose was enough because I sit right there. Prose is enough right up to the moment you notice it is not, and you usually notice from a diff you did not want.

Repo: github.com/anthropics/commerce-agents. It says "reference implementation, not maintained, no contributions" right at the top. Honest. Take the mechanisms, not the code.