AI App Builder Custom Instructions (2026): Where Your Standing Orders Actually Live

Quick answer (October 2026)

Every AI app builder lets you type instructions into a chat box. The question that separates them is whether you can write those instructions down once, have them applied automatically, and keep them when you leave.

Across the eight builders we track, there are four structurally different answers and three documented silences. Lovable and Bolt.new both run a two or three tier knowledge model that applies on every message. Replit runs the only system where the vendor writes instructions back to you. Base44 exposes instructions as a create-time API field on its white label surface and nowhere else. v0 saves instructions to your account but makes you tick a box to apply them. Bubble, Softr and Webflow document no persistent instruction mechanism at all.

The finding that matters most is Lovable's, and it cuts against the vendor's own product: Lovable gives a stronger written guarantee to an AGENTS.md file sitting in your repository than to the knowledge field sitting in its database.

The eight builders compared

Why this is a durability question, not a convenience feature

An instruction field looks like a way to stop repeating yourself. It behaves like a question about what survives.

Everything you write into a vendor's knowledge box is a second, invisible half of your project. It shapes the code, it is never compiled, and on most of these platforms it is not part of anything you can export. If you move, the code comes with you and the standing orders do not. That puts this axis directly next to what the vendor does with the material you hand it, because a knowledge field is exactly that: text you supply, stored on their side, read by their model.

So the useful question is not can I give it instructions. It is where does the instruction live, who may change it, and does it come with me.

Finding one: Lovable guarantees your file more strongly than its own field

This is the sharpest thing in the set, and Lovable documents both halves itself.

On the vendor's own field, Lovable publishes a caveat. Lovable, verbatim: "Workspace knowledge is always included together with project knowledge alongside project code and other context sources. However, in very long conversations with a lot of context, instructions may not always be followed consistently."

On a file in your repository, it publishes the opposite. Lovable, verbatim: "For technical users managing instruction files directly in their repositories, root-level AGENTS.md files are always read by the Lovable agent regardless of session length."

Always, regardless of session length, against may not always be followed consistently. The artefact Lovable does not store is the one it commits to hardest. For anyone weighing portability this is a free win: the instruction that travels with your code is also the instruction with the better guarantee, so there is no trade to make.

Lovable's structure around it is well specified. Knowledge sits at two levels, workspace and project, both capped at 10,000 characters, with one workspace knowledge per workspace that cannot be split across a subset of projects. Only workspace owners and admins can edit the workspace level. On conflict, Lovable, verbatim: "If the instructions conflict, Lovable is encouraged to prioritize the instructions defined in project knowledge, since they apply specifically to the current project."

Note the hedge there too. Encouraged to prioritize is not a precedence rule, it is a preference.

Finding two: the same 10,000 characters, opposite failure behaviour

Lovable and Base44 both land on a 10,000 character limit. They fail at it in opposite ways, and only one of them tells you.

Lovable's is a field cap. The number is published, the box holds that much, and you find out when you hit it.

Base44's is not a cap. Base44, verbatim: "Only the first 10,000 characters are sent. Longer text is stored in full but silently cut off in the prompt."

Your text is accepted. Your text is stored. Your text is visible when you go back and read it. And everything past the limit is dropped before the model ever sees it, with no error and no warning. A reader could paste in a 15,000 character policy, see it saved, and reasonably believe the last third is governing the build. It is not.

That is the kind of defect that cannot be caught by looking at the product, only by reading the sentence. Identical number, and the difference between the two is whether the system fails loudly or quietly.

Finding three: two vendors say in writing that instructions are advisory

The word instruction implies a constraint. On the two platforms that document this most carefully, it is explicitly not one.

Replit, verbatim: "Custom instructions may impact Agent performance. Agent is guided to follow them, but strict requirements aren't guaranteed. Shorter, more specific guidelines are followed more reliably."

Lovable's long conversation caveat above is the same admission in a different register.

This is worth taking seriously rather than treating as boilerplate. If you are writing a security requirement, a data handling policy or a compliance rule into one of these boxes, both vendors have told you in advance that it is a strong hint. Neither is being evasive. Both are describing how instruction following actually behaves, and both give the same remedy: keep it short, keep it specific. Base44 draws the line even more plainly on a neighbouring surface. Base44, verbatim: "A prompt changes the agent's instructions, not its permissions."

Finding four: Replit is the only builder that writes instructions back to you

On seven of the eight, instructions flow one way. You write, the agent reads. Replit runs that loop in both directions and is explicit about it.

replit.md is created for you, not by you. Replit, verbatim: "Agent automatically creates this file in your project's root directory using proven best practices." It must sit at the project root, the agent reads it on every request, and Replit, verbatim: "Agent can also update your replit.md file as it learns more about your project and makes changes to your application." You can edit it; you can delete it and have a fresh one generated.

Memories go further. They are authored by the vendor. Replit, verbatim: "Replit can write Memories while you work; they are contextual evidence, not executable instructions." They are private by default, sharing with collaborators is off by default, and precedence is stated: your explicit request and custom instructions outrank them.

The three way split is documented cleanly: custom instructions are workspace wide and always on, skills load only when a task matches, memories are retained context. Availability is tiered, with custom instructions on Pro and Enterprise workspaces and skills across the paid plans, and on Enterprise only admins can edit either.

Finding five: Base44's instructions are write once, API only, and white label only

Base44 has the most powerful mechanism and the narrowest door.

Both the custom instructions field and the replaceable system prompt live under the white label developer surface, which is in beta and has to be enabled for your workspace by an onboarding contact. There is no equivalent field in the ordinary app editor. Custom instructions are set through the custom_instructions parameter when you call Create app, on the same build turn API that carries Base44's cross site embedding flow, and they are scoped to one app rather than the workspace.

Then the constraint that decides it. Base44, verbatim: "You cannot add custom instructions to an app after it's already created."

Write once, at birth, through an API, on a beta surface. If the app exists and you did not pass the field, that door is shut. Against that, Base44 is the only one of the eight that lets you replace the vendor's built in capability guidance with your own system prompt entirely, which is the far end of the control spectrum. It is simply not available to someone building an app the normal way.

Finding six: v0 saves your instructions but will not apply them for you

v0's Instructions are reusable prompts with built in presets for concise responses and plan mode. You create one with a title and a rule, and v0, verbatim: "Your instruction is now saved to your account and available across all your chats and projects."

Available, not applied. To use one you open the prompt bar menu, tick the instructions you want, and v0, verbatim: "Checked instructions will be applied to your messages until you uncheck them."

That is the only one of the eight where persistent means stored rather than active. It is a defensible design, because an opt in instruction cannot silently degrade a conversation you did not intend it for. It also means a rule you consider non negotiable is one unticked box away from not existing, and nothing in the product will tell you.

Finding seven: Bolt.new has the deepest tiering

Bolt is the only builder of the eight with three knowledge levels rather than two.

Account knowledge applies, Bolt.new, verbatim: "across all of your projects". Workspace settings carry a shared team layer. Project knowledge applies, Bolt.new, verbatim: "for a specific project". All three are described the same way: background instructions the agent uses automatically so you do not repeat them in every prompt.

Skills sit alongside, with the split stated plainly. Bolt.new, verbatim: "Skills only apply in certain situations (defined in the skill description), while knowledge applies to every prompt." Skills exist at workspace and project level, can be written by hand, drafted by Bolt or imported, can be toggled per project, and can be invoked by typing a slash and the skill name. Bolt also states that skills are available on all plans, which is the most generous availability statement of the three vendors that document tiering at all.

The three silences, and what each one is instead

Bubble, Softr and Webflow document no persistent instruction field. In all three cases the absence is coherent rather than an oversight.

Bubble runs an ambient context model. Its agent reads the structure of your app and whatever you have selected in the editor: Bubble, verbatim: "If a specific element is selected, the Agent uses that as context. If a workflow is open, it can suggest changes to that workflow." There is no knowledge field, no conventions store, and context is scoped to the thread, with the docs describing how Bubble, verbatim: "to start a new chat with a fresh context". For a visual builder where the app itself is the specification, that is a reasonable position.

Softr is the same shape. Softr, verbatim: "The AI knows which page you're on, which data sources your app uses, and the fields available in each table." Its AI Co-Builder page documents its own limitations section candidly and contains zero occurrences of instruction, knowledge, convention, guideline or rule.

Webflow inverts the question entirely, and it is the second time we have seen it answer an integration question by pushing the work outward rather than building a field. Its skills are not something you give Webflow. They are pre built agent capabilities Webflow gives you, installed into your own agent with a single command, npx skills add webflow/webflow-skills, targeting Claude Desktop, Claude Code, Cursor and Windsurf. The persistent instruction lives in your agent's configuration, on your machine, because in that model Webflow is the thing being operated rather than the thing doing the building. Which means, uniquely among the eight, your instructions are portable by construction: they were never on Webflow's side to begin with.

An instrument note, because the word agent ruins this search

We publish our method, so here is the part that nearly went wrong.

A naive search of v0's documentation returns 376 occurrences of agents.md. Every single one is the documentation site's own footer line, a repeated pointer reading "For agent-facing discovery, including API and MCP surfaces, see /docs/agents.md", which appears on 188 pages and is counted twice per page because of the markdown link format. Zero of the 376 are about a project level instruction file. v0 documents no repo level AGENTS.md support at all.

The same trap sits on three other vendors. Bubble's single hit is a page about connecting to external AI models. Softr's is a feature for auto filling database content. Base44's are SDK interface docs for agents running inside the app you built. Webflow's developer index hit is its own instruction block addressed to AI crawlers.

Five vendors, five tempting matches, five different meanings, none of them this axis. If you are evaluating builders on this and you grep for the word agent, you will get a confident and completely wrong answer.

Verdict, October 2026

If the instruction has to survive you leaving, there are only two real answers today: a root level AGENTS.md on Lovable, which the vendor commits to reading more firmly than its own field, or Webflow's model where your instructions were always yours. Everything else is text in somebody else's database.

If you want depth and your team is staying put, Bolt.new has the most complete tiering at three levels plus skills on all plans, and Lovable is close behind with the clearest written specification of precedence, limits and conflict behaviour.

Replit is the most interesting and the most two sided. It is the only platform that maintains the artefact for you, which is genuinely less work, and the only one where the vendor is also writing into your context store. Whether that is a feature depends entirely on whether you intend to read replit.md and the Memories list. If you do not, something is steering your builds that you have never looked at.

Base44 has the strongest ceiling and a door most readers cannot open. v0 is fine so long as you remember that saved is not applied.

Bubble and Softr are not failing at this so much as declining to compete on it, and if you are building inside a visual editor where the app is its own specification, that may cost you nothing.

One rule holds across every vendor that documents this properly: keep it short. Replit, Lovable and Base44 all say so independently, and two of the three say in writing that a long instruction is a less reliable one.