Overview

From laptop to production

A tool built with a coding agent rarely stays what it started as. A spend dashboard someone made for themselves reads live data a month later, the whole finance team opens it the month after that, and by the end of the year the quarterly close depends on it. Sometimes an engineering team takes it over.

A tool can change in kind along the way, too. Many start as a skill, instructions someone wrote down so their coding agent does a task the same way each time. The skill becomes a page, the page starts reading live data, and the page becomes an app that saves records or an agent that works on its own. See Skills.

Each stage raises a new question: where the tool runs, how it reaches the data, who can open it, what happens when it breaks, and who owns it now. Without a place to run, each answer is improvised: a laptop left open, a password in the code, a link pasted in a chat. Valet answers each one in the same place, so the tool can keep growing without being rebuilt.

A personal tool#

Someone asks their coding agent for a tool that solves their own problem. It works on their laptop, at an address only that laptop can open, and it stops when the laptop sleeps.

With Valet, they ask the agent to publish it. Valet tells the agent to read your organization's skills first, and the agent then publishes the tool as a skill, an artifact, an app, or an agent. An artifact, app or agent gets its own address and runs whether or not the builder's laptop is open. An artifact is private to your organization from its first publish.

Connected to data#

Most tools are only useful with real data, such as last week's tickets or this quarter's pipeline. The usual shortcut is a personal API key pasted into the code, which then travels wherever the code goes.

Valet gives tools three ways to reach data, none of which put a credential in the code:

• A connector gives artifacts and agents the tools of a service your company uses. An administrator sets it up once, and Valet holds the credential. See Connectors.
• A resource gives an app a service it needs to run, such as its own PostgreSQL database or access to an LLM. Valet provisions it and hands the app its connection details. See Resources.
• An env var holds a setting or a secret the tool reads when it runs. Valet stores secrets encrypted.

Data access explains which to choose.

Shared with the team#

The builder sends the link to a teammate, and the tool now matters to more than one person.

Members of your organization sign in to open what it publishes. A published skill needs no link at all: every member's coding agent finds it when the work fits. When a tool should reach further, any member can protect it with a password or make it public. Everything the organization publishes shows up in one place, so people can find a tool without knowing its address. See Organizations.

Load-bearing#

A team's weekly process now depends on the tool. If it stops, someone notices before lunch.

Valet keeps it running the way a production service runs:

• Every publish creates a new release, and each release keeps its source. If a change goes wrong, publish an earlier release again.
• Logs show what the tool did. Log drains send them to the system your company already watches.
• An app runs as many processes as it needs, and Valet restarts a process that crashes.
• An agent keeps working on its own: on a schedule, in Slack, or when another system calls it.
• The tool belongs to your organization, so it keeps running when the person who built it is on vacation or leaves.

Handed to engineering#

Some tools grow past what their builder should maintain. An engineering team takes over, or the tool becomes part of a product.

Valet keeps every release's source in git, so an engineer starts from the exact code that's running. The tool can stay on Valet with its new owners, or they can take the source to their own repository and infrastructure.

Engineers can shape that code before the handoff. Valet tells every coding agent to read your organization's standards before it publishes, so the practices your engineers write down reach a tool from its first version. See Governance.