Existing System

You are not starting from scratch. Whatever runs your business today — a custom app, a Salesforce org, a folder of spreadsheets — already contains most of the decisions the new system has to make. Existing System is where you hand those decisions over, so the agent starts from them instead of inventing its own.

Internally, and in the API, these files are called artifacts. That is the last time this page uses the word.

It starts with one question

The first real screen asks where your system is moving from: built in-house, generated by an AI tool, a SaaS product you subscribe to, a no-code app, spreadsheets, an older business system, or no software at all — a process you run by hand today, or nothing built yet. That single answer decides everything after it.

It matters because relevance is derivable. A Salesforce customer has no source code and no database schema of their own, and asking for them is not neutral — it reads as a checklist they are failing. Answering the source question once prunes the list to the four or five things that actually exist for you, and lets the product say “you won’t have this, and that’s normal” out loud.

If you already answered what kind of system you have when the project was created, this is filled in for you. Nothing is asked twice.

Two of the answers have no software behind them and share a card: a process you run by hand (paper, email, phone) and nothing built yet. They lead to different questions — a manual process is asked about its forms, its rules and who signs off; a new build is asked about designs, a brief and the rules you have already settled — so the card asks which of the two once you pick it.

A project with nothing to replace still gets a short version of this. There is no system to describe, but a sketch, a proposal or a rule you have already decided is a decision you should not have to make twice, and five minutes here is cheaper than re-explaining it in chat.

A short list, ranked

You are asked about eight or nine things, not twenty-two, in two tiers:

• Essential — four items whose absence materially changes what gets built. Each gets a screen of its own.
• Helpful — three to five items that improve accuracy without changing the shape of the build. They share one screen.

Every item is introduced with the same five things: what it is in one sentence, what the agent does with it, what the agent has to guess without it, how to prepare it, and — behind a disclosure — concrete instructions for getting it out of your particular system.

That fourth one is the important one. Rather than marking things “required”, the product tells you the actual cost of skipping each item: “the agent designs a data model from your screens; expect to correct table and field names later”. If you read that and decide to skip it anyway, you have made an informed decision, and nothing complains.

”We don’t have this” is an answer

Every item offers four outcomes, and three of them are not an upload:

The first three all count as settled, and all three are passed to the agent. This is the point most people miss: “nobody ever wrote the approval rules down” is information. An agent that knows a thing does not exist stops asking for it, stops treating its absence as an oversight, and asks you to describe it instead. A blank tells it none of that.

Only Later leaves the item open.

Preparing what you send

Preparation is part of the ask, and the product checks it rather than requesting it. When you choose a file, it is inspected in your browser, before anything is uploaded.

For an archive it reads the table of contents — file names and sizes, nothing decompressed — and tells you what it found: how many files are node_modules, .git, dist or build output, and how much of the size they account for. It offers to strip them, or gives you a command to run if the archive is too large to repack in a browser tab.

There is a hard 500 MB limit per file, checked before the upload starts. It exists because analysis reads the whole file into memory, not because of storage.

Credentials are refused, not warned about

If the inspection finds something that looks like a credential — a .env, a .pem, a private key, a service-account JSON — the file is not uploaded. You are shown the exact paths and given two ways forward: remove them and upload, or cancel.

This is the one part of this page that is not a convenience. Everything you attach is read by the agent and mirrored into its working directory, so a leaked key does not sit inertly in storage — it enters a model’s context and a shell’s working tree. .env.example and .env.sample are recognised as examples and pass through untouched.

For a text file the check is different: inline keys are shown to you in context, and the upload proceeds against a redacted copy — the surrounding content is exactly what the agent needs, and only the key itself is replaced.

If the check is wrong about a file you genuinely need uploaded, there is a second, explicitly-labelled button to override it. It is recorded against the file.

What happens to a zip after you upload it

An archive is not filed away as one opaque blob. Once it lands, the product opens it on the server and reads what is inside, so the agent can search your actual source instead of guessing from the questionnaire.

Three things are dropped before anything reads it, and none of them are recoverable from what the agent sees:

• Credentials. The same rules the browser applied are re-run on the server, on every format, with no override. A .env, a private key or a service-account JSON is removed from the expansion and counted. The override button covers what gets stored; it does not cover what gets read.
• Dependencies and build output. node_modules, .git, vendor, dist, target, caches, compiled binaries and oversized media. They are reproducible and carry no design information.
• Anything that is not text. Images, binaries and a .txt that turns out to be a database dump are listed but not opened.

The row then gains a one-line receipt — “412 files readable · 4,180 skipped (dependencies, build output) · 2 credentials removed” — which is the honest version of the promise the upload screen made. It appears within seconds of the upload; you do not have to send a message first.

Very large archives are read up to a limit rather than refused, and the agent is told when it is looking at a partial view. .zip, .tar, .tar.gz and .tgz are supported; .rar and .7z are not, and an archive inside an archive is listed but not opened.

If you can connect the repository instead, do that. A zip is a photograph of one moment; a connected repository keeps up. This exists because a great many systems — an agency-built app handed over as a folder, an export from an AI builder, an in-house tool on a server nobody has logged into for years — will never have a repository to connect, and their code is still the best description of them that exists.

After the intake

Finish and you get the list: one row per file, with what it is, your own note about why it matters (editable in place), its size and its age. Above it sits one line — “Essentials: 3 of 5 · 2 marked unavailable” — and a Review what’s missing button that reopens the summary.

That line is the whole answer to “how do I keep this up to date”. It is the only thing on the page that can go from green to amber.

Source code is not counted in it. It gets a screen like every other essential, because what to send and how to clean it is worth reading, but skipping it leaves nothing outstanding. Your code is not added to every conversation — the agent goes and reads the part it needs, when you ask for something that depends on how the old system behaved. If you would rather describe the behaviour you want in your own words, that is a complete answer on its own.

Add file is there for anything off-list; it runs the same checks as the intake.

What you brought is a reference, not an archive

Nothing you attach is filed away for later. From the moment it lands it is part of what the agent works from: the one-line catalog entry for every item sits in front of it in every conversation, and it goes and reads the contents of the ones a request actually depends on. Ask for a customers page and it reads your old customers table before inventing one.

It works in the other direction too — you can question the old system yourself, at any time, in the Agent:

In the old system, what do we keep on a customer’s profile?

Which rule decides when an order needs a second approval?

Who was allowed to issue a refund?

This is the part people underestimate. A system that has been running for years accumulates decisions nobody remembers making — a field added for one awkward client, a rule that exists because of an audit five years ago, a status nothing sets any more. The people who knew have often moved on; the behaviour is still there in the schema, the screens and the code. Asking the old system is faster and more honest than trying to remember it, and every answer is one less thing you have to re-decide for the new build.

Answers come from what you actually brought. If the rule you are asking about lives in code you skipped, the agent tells you it cannot see it rather than guessing — which is usually the moment to go back and attach it.

Keeping it current

A file describes your old system as of the day you uploaded it. Files on essential items are marked may be out of date when the project has moved on since, or after 90 days if someone is still changing the old system. Replace on a row swaps the file and keeps everything else.

Finishing with gaps is fine

Nothing here is a gate. You can complete the whole intake having attached nothing at all, having instead told us what does not exist — and that is a legitimate, useful outcome. The final screen lists what is missing and what each gap will cost, as a forecast rather than a warning, and then lets you finish.

Next: Your first Ask · Design