How aidrop works

aidrop keeps a repository, the knowledge about it, the rules it is worked on by, who may reach it, and where it runs, in one record called a Project Workspace. An agent connects to exactly one of those and reads only what belongs to it.

It does not write your code. Your developer or your agent does that, and the repository stays where it already is. What aidrop adds is the part that usually lives in somebody's head or in a chat log, and therefore does not survive them leaving.

Everything below is a mechanism, not a policy. Where a boundary holds, it holds because of how the system is shaped — and where something is not built or not promised, that is said too.

The words, before the argument

Eleven terms carry the rest of the document. They are used precisely and they are not interchangeable, so it is worth two minutes here rather than a wrong reading later.

Team

The tenant. Every person belongs to exactly one, and everything — Projects, billing, access — hangs off it.

Project Workspace

The durable unit. One record holding a repository, the knowledge about it, the working rules, scoped access, and delivery state.

Project Takeover

Bringing software that already exists under that record: the current revision read, an owner named, and the blockers stated before anyone continues.

Grant

Scoped, revocable access an agent holds to exactly one Project. It resolves the Team, the Project, and the actions permitted — and nothing wider.

Work instructions

The one active instruction set a Project runs by. Immutable by version; one set active at a time.

Skill

A versioned playbook for how an agent works in this project — architecture, storage, changes, tests, delivery. Optional, and additional to the instructions.

Template

A monorepo shape plus a runtime contract, used to start a project that does not exist yet. Also called a starter.

Runtime contract

What the platform needs in order to run the code: runtime kind, container port, health endpoint, resource class, and the external services required.

Preflight

The evidence check run against a connected repository. It reports supported, assisted or unsupported, and lists what is missing rather than guessing past it.

Managed Runtime

Where a Project's application runs when aidrop hosts it. A cluster is enrolled; the control plane reaches it over one HTTPS address with one token.

MCP

The protocol an agent speaks to reach a Project. The same keys and scopes also work over REST.

What is discussed, and where

Four names for one thing

The product is described at four levels and they are not interchangeable. Collapsing them into one feature list is how this gets explained badly — a customer hears a memory tool bolted to a hosting provider, which is a fair reading of a feature list and a wrong reading of the product.

Software Continuity — the outcome

Software stays understandable and operable after the person, team or session that built it is gone.

Project Takeover — how you arrive

Existing software is brought under control: the current revision read, an owner named, and the blockers stated before anyone continues.

Project Workspace — the durable object

One record holding the repository, its knowledge, the working rules, scoped access and delivery state.

Project Control Plane — the architecture

The systems that govern that record. Internal language; you will not meet it in the product.

Those are the words. The next two pages are the shape they describe — first from outside, where only the callers and the dependencies are visible, then from inside.

The system, from outside

Three kinds of caller reach aidrop: an agent over MCP, a person over a signed-in session, and — once you publish — whoever has the address. They arrive at one control plane, which holds the Project record, decides access and drives delivery.

Open the middle box and it separates into two groups with a real boundary between them.

The system, from inside

On the left, the processes that are ours. On the right, a machine that holds customer code. The control plane calls the cluster's own public address; the cluster calls nothing back.

The database is the only source of truth. The search records are derived from it and can be discarded and rebuilt, which is why losing one is an inconvenience rather than an incident — a distinction worth having before you ask what our backups look like.

Every one of those separations is load-bearing. The next page says which, and what each refuses.

Security: where the boundaries are

None of what follows is a policy. Each is a shape the system was built into, which is the only kind of boundary worth telling a customer about — a policy is a promise about future behaviour, a shape is a statement about present behaviour.

A grant resolves one Project

Every record carries the Team it belongs to, and Project records carry the Project as well. A grant never falls back to another Project or to the Team's wider context. There is no broader scope for it to land in, so the failure where an agent quietly reads more than it should has nowhere to occur.

Two edges, never one

The edge in front of aidrop and the edge in front of customer applications are separate instances, and the driver that creates customer routes is given only the customer edge's address. A bug in route provisioning can break a customer's address; it cannot rewrite ours.

A guard that cannot decide, denies

Anything protecting an address fails closed. The component that authorises a closed address holds a public verification key and nothing else: it can refuse, and it can allow what someone else already signed, but it cannot mint permission, because it was never given a key that could.

Your code is handed no credential of ours

Platform cookies and tokens are stripped before a request reaches an application, and the build step that runs your repository is given none either. Nothing in the container was ever handed the means to act as aidrop — not withheld from it, never issued.

One way out, and it is recorded

A project's network reaches the internet through a proxy and nowhere else, so what an application talks to is a fact rather than an assumption.

Content is judged when it is published

A closed address is seen only by Project members and needs no judgement at all. The decision happens when authorisation is removed — against what the internet will actually see, not against the sources a Project was built from. That also means onboarding does not depend on a model being up, which is a lesson learned the expensive way.

Three ways to decide who signs in

Those boundaries say what a caller may reach once it is identified. Identity itself is a separate decision, and there are three sensible answers rather than one imposed on you.

Users held in aidrop. A project or internal tool gets its own users without anyone standing up a separate identity layer for it. Access stays attached to the workspace and the people who need it.

The company identity you already trust. Connect the sign-in model your organisation runs, so people enter internal products with an identity your team can recognise and administer.

The product's own protocol. A deployed product can keep or connect through its own authorisation protocol when that is the right boundary for its users, systems and data.

These are not the same lock. Opening a product to an audience does not open the Project behind it: the people who may use a running internal tool and the people who may read its repository, its knowledge and its delivery record are two lists, and they stay two lists.

Boundaries decide what an agent may reach. What it should do once it is there is a separate question with a separate answer.

Skills: the working rules a Project owns

A skill is a versioned playbook for how an agent works in this project — architecture, storage, changes, tests, delivery. Not a runtime component, and not a block of prompt text pasted into a session and lost with it.

The words this section uses

Six of them, and the difference between two in particular decides how the whole thing behaves.

Library skill

One of the twenty-six aidrop maintains. It lives in a registry in code, so it is the same text for every customer.

Skill pack

The set a Project carries. A template recommends one; the owner can uncheck any of it before the Project is created.

Team addition

What your Team appends to a library skill. Stored per Team per skill, append-only, and never mixed into aidrop's text.

Attach

Copying a library skill into a Project. Happens once, when the Project is created.

Load

An assistant asking for a skill mid-session. This is the moment composition happens, and the reason it matters.

Retained version

A pack keeps its earlier versions. What an assistant was told last month is still readable this month.

Twenty-six of them, and they are ours

Library skills live in a registry in code rather than as rows in a table, so nobody can quietly edit what every customer is told. A template recommends a pack by default; the Project owner can uncheck any of it before creation, or hide one later without deleting what it already said.

Your team writes its own on top

pnpm rather than npm. Migrations reviewed before merge. Never touch billing without asking Dana. That knowledge used to live in whichever session happened to learn it, which is the loss this product exists to prevent. It is stored per Team per skill, append-only, and appended whenever an assistant loads that skill.

Attach happens once. Load happens every time.

This is what the vocabulary above was for, and it is the whole behaviour. A library skill is attached — copied into a Project — when the Project is created. Your addition is not copied with it. It is joined at load, every time an assistant asks for that skill.

Appending at attach would have frozen it: an owner who edited their own rule would change nothing for any Project that already existed — and editing something and seeing nothing happen is the first thing anyone would do. Composing at load means one edit reaches every Project, present and future.

It costs the reproducibility a version number buys, so the load response carries your addition's own id and timestamp beside the pack's version. What an assistant was told is still answerable afterwards; it is answered by two records instead of one.

Marked, never blended

Your text arrives under a heading naming whose it is, followed by an instruction to follow it where it disagrees with ours and to say that it did.

Bounded, and refused if it looks like a secret

Twenty thousand characters, and rejected outright if the text looks like a credential. It is handed to an assistant and stored durably, which is exactly the shape that ends up holding a pasted token. Clearing it writes an empty record rather than deleting one, so the history still shows an addition existed and when it stopped.

Loaded on demand, not poured in at the start

An agent does not receive every skill the Project owns the moment it connects. It discovers what is available and loads the one it needs for the work in front of it. A session changing a migration does not have to carry the review process for the front end in order to do it.

Where skills sit next to the other two

Three things are easy to confuse and do different work. A template defines the repository structure, the runtime stack, the defaults and the pack that fits that kind of project. Skills tell an agent how to work inside it. Project knowledge records the facts that keep changing: why the system is shaped this way, the constraints already discovered, and what the next session must not undo.

Review packs, and what they do not claim

Optional security packs put code and delivery review on a named footing: OWASP guidance on common application risks and safer patterns, ASVS requirements so security expectations are testable rather than asserted, and ISO 27001-aligned practices. That last one is a review workflow — it does not claim, and must not be read as claiming, that anyone's organisation is certified. Where a process needs something more specific, an RFC skill can be added to the Project's own pack.

Skills say how to work in a project that exists. A template answers the case where it does not yet.

What a new project starts from

Templates cover the work people most often bring out of a coding assistant: SaaS products, full-stack web applications, landing pages, storefronts, internal tools, bots, API backends, integrations, automations. Django, a Node service and a custom monorepo remain there for the shapes that fit better.

What is in the catalogue

Twelve product shapes, plus a plain service and a custom monorepo for the cases a product shape does not frame well. The list is deliberately shapes rather than stacks: a customer arrives knowing what they are building, not which layout the platform prefers.

AI SaaS product

Accounts, subscriptions and an assistant at the centre of the thing being sold.

Full-stack web application

Its own database and server-rendered pages, in one repository.

Landing page

A single page and a form, live at an address the same day.

E-commerce storefront

A catalogue, a cart and a payment provider.

Booking or marketplace

Two-sided listings, availability, and money moving between the sides.

Internal tool or CRM

Records, roles and a private address — the shape most agent work ends up being.

API backend

An interface other things call, with a contract that has to keep working.

Frontend application

A client over an API somebody else owns.

Integration service

Moving data between two systems on an agreed shape.

Automation

Scheduled work with no interface of its own.

Telegram bot

A conversational surface over the same Project.

Content site

Pages generated from a source, published quickly.

A template is a monorepo with a contract

It carries three things: recommended skills, an expected layout — applications, services, packages, docs — and a runtime contract naming the runtime kind, the container port, the health endpoint, the resource class, and the external services the code needs.

The contract is referenced, not restated

Each template points at an entry in one shared runtime registry and states only where it genuinely differs — a Next.js product overrides the health path, most override nothing. That is what keeps a chosen template and a detected repository speaking one vocabulary instead of two dialects that drift.

One list behind three doors

The dashboard, the public API and the MCP tool are thin routes over the same registry. They used to be copies. When the copies were finally compared field by field, every one of the sixteen starters disagreed about its resource class — and the parity test had passed the whole time, because it compared only names. Adding a starter is memorable; changing a number is not.

A build recipe per starter

Not a suggestion in a README: a build that is known to run here, published with the starter, so the first deploy is not a research project.

Before that: what the thing actually runs on, and what it is allowed to keep.

Resources: what a project runs on

Two things are sized separately and it is worth keeping them apart. The application has an envelope — processor and memory — and the services behind it are their own instances, billed and scaled on their own terms.

What the application gets

Five envelopes, and they are copied into a profile rather than looked up, so a later policy change cannot quietly resize a workload somebody already reviewed.

The first three double cleanly on a shared node, where memory rather than processor decides how many projects fit. The last two need a bigger allowance than the tier below has in total — which is a boundary drawn by arithmetic rather than by a rule, and those are the boundaries that do not need defending when the numbers move.

Nothing here has a disk. An application runs on a read-only root with scratch space that does not survive a restart, so anything that must outlive one lives in a service.

What a service can be

Only the cache is allowed to forget, and that is the whole reason it is a separate line rather than a setting. A database that forgets is not a database and a queue that drops its messages on a restart is not a queue, so both of those are given a volume. A cache is not, because giving it one would promise a durability nothing backs up.

The last column is about the service, not about any particular message. The broker keeps its volume; a message survives a restart only if the application published it as persistent onto a durable queue. We keep the store — what goes into it, and how, stays your code's decision.

An instance holds databases; a Project links to one

The instance is the billed unit — one per Team per kind — and a Team creates as many databases inside it as it needs. A Project links to a database rather than to the instance, and the link carries the variable name the application will read.

Deleting a service leaves its volume behind on purpose, and the next instance of the same kind picks that volume back up. Data outliving the thing that served it is the safer default in both directions.

There are no backups and no restore promise. A dump is yours on request and we keep no copy of it — which is a smaller offer than it could be, and a true one.

Three builds, and what each of them asks for

Which plan a build actually needs

The same question from the other side. A plan is a pot of capacity and a set of services, and the useful way to read one is not what it includes but where it runs out — because that is the line a build crosses without being told.

Before any of them there are seven days of the whole thing — one application and one database, every connector, unlimited reads — which exists so the loop can be tried before a tier is chosen. What it is not is a plan: nothing stays running on the free tier a trial lands on.

Two boundaries above are worth stating on their own, because both are usually discovered late. An application never has a disk, on any plan — so on a tier without a service there is genuinely nowhere to keep anything. And a cache and a broker arrive together, at the tier where a Team is running enough for either to be the thing that was missing.

Which leaves the last question — what happens between a commit and something you can open.

From a commit to an address

Five steps, each of which leaves a record. If it stops, the record says at which stage and why, rather than leaving you to infer it from a log.

1. 01

   Connect

   A GitHub repository, or one in your Team's own Git. The code stays where it is; aidrop reads a bounded snapshot.

2. 02

   Ground

   Assign an owner, record what the Project knows, run the preflight — which states the blockers rather than guessing past them.

3. 03

   Authorise

   Issue a Project-scoped grant to the agent you use. It reads this Project's knowledge and its active rules, and nothing outside them.

4. 04

   Build

   One pipeline record with explicit stages and, if it stops, a stop reason. The step that runs your code holds no credential.

5. 05

   Serve

   A closed address first, reachable only by Project members. Publishing is a separate decision, reviewed before the lock comes off.

Hosting is gated, and when the gate is closed none of this stops being useful: the record, the rules and the access are the part that never depended on where the application runs.

Try it against a codebase you already have

Seven days, no card. Connect a repository, point your agent at it, and read the record it produces before you decide anything.