From sandbox to production

There is no promote button. Production is written by the same verbs as the sandbox, with --prod, by a person whose production switch is on, or by CI on a production server token. This page is what to carry across, how, and how to take it back.

What travels, and how#

Each kind of thing an agent has crosses on its own path. The code goes with a deploy; settings, documents and numbers do not.

The codeA deploy: pinecall deploy --prod, or your own server. SettingsVoice, models, greeting, what it knows by heart: pulled as a file and pushed. DocumentsProduction's own base, written there or pushed once. TestsNever: they run in CI, in the sandbox, before the deploy.

what	in the sandbox	how it reaches production
the class and its tools	your repository	`pinecall deploy --prod`, or `pinecall start --prod` on your server
settings: voice, models, language, greeting, how a call ends, memory policy, what it knows by heart, which bases it reads	the team's settings (`--team`)	`pinecall agent pull --team`, then `pinecall agent push <file> --prod`; the memory policy and the bases travel in the file
the lexicon	`pinecall lexicon --team`	`pinecall lexicon add … --prod`, or the agent's Lexicon tab in production's console
the documents it searches	the sandbox's base	the agent's Knowledge ▸ Docs in production's console, or `pinecall docs push --prod`
goldens and personas	the agent's	never: CI runs them on a sandbox token
calls and what memory learned	the sandbox's own	never: each keeps what happened in it

Step by step#

1. Hold the agent to its goldens#

In CI, on a sandbox server token: pinecall test, pinecall docs eval, pinecall remember and pinecall memory eval. Each exits 1 when something did not hold, and a red run stops the deploy. See Testing in CI.

2. Carry the settings#

See how the sandbox's settings differ from production's, then write the team's to a file:

Terminal

pinecall agent diff --against production
pinecall agent pull --team > settings.json

Then push the file as production's next version:

Terminal

pinecall agent push settings.json --prod

Keep settings.json in git, and the push is a step of your release. The file names the bases the agent reads, so production's base must exist under the same name before the next call: step 4.

3. Carry the lexicon#

Word by word, pinecall lexicon add Vidal --say "Bidal" --prod, or on the agent's Lexicon tab.

4. Fill production's knowledge base#

Production searches its own base. Write its documents in the agent's Knowledge ▸ Docs on production's console, or start it once from a folder:

Terminal

pinecall docs push --prod

Nothing is attached again: the settings pushed in step 2 already say which base the agent reads.

5. Ship the code#

Deploy to Pinecall with pinecall deploy --prod, or restart the process on your own server.

6. Point a number at it#

A number answers in the sandbox or in production, never both. Import it into production with pinecall numbers import <+number> --agent <slug> --prod, or Add a number on the console's Numbers. You do not need a sandbox number: a developer's own phone reaches their sandbox copy with pinecall line from <+their-number>.

A deploy never pushes the knowledge base, and pinecall docs push --prod replaces production's base whole, including what was written in the console. Push from a folder once, then edit in the console, or always push from the folder. Mixing the two loses the console's edits.

Changes without a deploy#

Settings, the lexicon and documents are kept by the gateway, so they change without a deploy. The next call hears the change:

Terminal

pinecall agent set --greeting "Clínica Norte, how can I help?" --note "shorter" --prod
pinecall agent knowledge edit --prod

The same edits are on the agent's Configure screen in production's console, by somebody whose role and switch allow it.

Rolling back#

what went wrong	how to take it back
a settings push or edit	`pinecall agent history --prod` lists every version, who set it and why; `pinecall agent rollback <n> --prod` brings one back as the next version
a release of the code	`pinecall deploy rollback <n> --prod`, or the release before on your own server
the base	push the folder again, or fix the document in the agent's Knowledge ▸ Docs

Nothing is rewritten: a rollback is always a new version or a new release, and the history says so.

Next steps#

Sandbox and productionWhat each holds and who may act in it. Knowledge basesPushing, attaching, and how a turn reads a base. Agent settingsEvery setting that lives outside the code. Testing in CIThe gate before the deploy.