Putting AI to work across your business
Lessons from a workshop with 100 global founders and building Valet at Turnkey: memory, workflows, guardrails, and measuring useful work.
In this note · 6 sections
When you give five AI agents work at once, the bottleneck often moves to the person reviewing their output. You can spend more on models, generate more work, and still finish the week with the same amount shipped.
I recently ran a workshop for 100 founders from around the world called How to 4x your business with AI. The most useful part was a framework for turning individual AI sessions into work a company can repeat: memory, workflows, guardrails, and metrics.
Those are also the problems we’ve been working through at XORS while building and piloting Valet with Turnkey. Valet gives agents a place to work in the background, with connected tools and human approvals. Using it inside a real company has taught us where delegation breaks down.
The workshop title sets an ambition. Getting there means counting useful work after you include the time people spend setting up, checking, and correcting it.
Memory saves you from briefing the same employee every morning
An agent that forgets your team, your decisions, and yesterday’s work needs you to explain them again. That repeated briefing becomes expensive when several people use AI every day.
In Valet, agents keep short Markdown notes organized by project, person, and preference, alongside a journal of their work. A nightly workflow reviews a slice of that memory, checks facts against connected tools, and consolidates notes.
The technical detail matters: these are inspectable documents backed by Postgres, with full-text search. A human can read a note and correct it. We can inspect what the agent will retrieve without guessing what an embedding represents.
Keeping memory accurate takes ongoing work. An old ownership decision can send an agent to the wrong person. A duplicated instruction can contradict its replacement. Recording where a fact came from, and reviewing it later, is part of the system.
For a founder, the first version can be small: a shared project brief, a decision log, and a record of completed work. Give the next session a reliable way to pick up where the last one stopped.
Workflows stop paying a model to decide the obvious
In the workshop, I used a release report as an example. A model may need judgment to identify which changes matter. Once the report is ready, code can send it to a known Slack channel.
Valet workflows let us combine those steps. A model handles the research and returns structured output. A tool node takes the relevant field and posts the message, without another model call to decide how to send it.
That distinction changes the economics of repeated work. Every fixed step you move into code removes another opportunity for the agent to wander, repeat itself, or spend tokens choosing an action you already know.
It also makes failures easier to locate. Did the research miss a change? Did its output fail to match the expected structure? Did Slack reject the message? Each failure needs a different fix.
Background work needs persistence, too. Valet stores queued work and workflow checkpoints in Postgres. Human approvals suspend execution through durable decision gates. A restart must preserve a pending approval rather than silently treat it as permission to continue. External actions still need duplicate protection and a check of the actual result.
The practical starting point is a task you already perform repeatedly. Run it manually with an agent, find the steps that stay the same, and make those steps explicit.
Guardrails make delegation possible
An agent reads code, documents, and tool responses written by other people. Any of that text can contain instructions to do something outside the task. A rule in the prompt gives guidance, but the application must enforce access.
Valet gives each session its own sandbox for running commands. The API manages authentication and tool access outside that environment. This separation lets us limit what agent-written code can reach.
We also learned that sandboxes need an operational lifecycle. Idle environments accumulated until they exhausted capacity and new tasks could no longer start. Hibernation, expiry, and cleanup became part of making the product usable.
Credentials need a separate boundary. Valet’s secret broker lets a command name a 1Password reference and receive the value in its process environment, avoiding a tool response that puts the credential into the model’s conversation.
That mechanism has limits: the process using the credential can read it. It does not make arbitrary code safe, and a container alone does not establish the right permissions. Credential scope and the commands allowed to use it still matter.
For recurring work, start with read-only access and a reviewable draft. Add permission to act when the result and failure behavior are clear. The agent’s instructions should describe the task, while the application controls what actions are possible.
Metrics should count the result you wanted
An agent saying it assigned a reviewer is easy to generate. The useful check is whether GitHub shows the right reviewer on the pull request.
Valet’s evaluation cases apply that principle to behavior as well as output. One case puts a malicious instruction inside a tool result. Passing means the agent leaves the protected note alone, even though the returned text tells it to delete it.
Cost needs the same discipline. The workshop included an energy team’s report that, after roughly $60 of model use, its power-load processing fell from 89 minutes to 15. That is one reported task improvement, with human guidance involved. It makes the spend understandable because there is a concrete result attached to it.
A low monthly bill tells you little if people spend hours repairing the output. More tool calls per token can indicate an efficient workflow, but those calls may include failures. More pull requests can indicate throughput, but they can also increase the review queue.
For the task you choose, record the cost of a completed, accepted result. Include model spend and the human time spent on setup, review, and rework. Track failures and the time to finish alongside that cost.
The pilot made setup and review part of the product
One lesson from piloting Valet has been how much work sits between a promising demo and a workflow someone trusts each week. People need help connecting the right data, defining the output, and understanding why a run failed.
That investment can be larger than they expect. If the first few runs require repeated rescue, people stop using the workflow before it earns back the setup time. A stronger model can help with difficult reasoning, but it cannot fix missing source data or an unclear definition of success.
Review capacity also needs a budget. Running more agents in parallel is useful when someone can verify their results. Otherwise, it produces a growing queue for the same reviewer. Small, checkable outputs give people a better chance of keeping up.
A useful place to start on Monday
Pick one recurring task with a named owner and a result you can verify. A weekly report is a reasonable candidate when you can check it against its sources.
- Record how long the task takes today, including review.
- Give the agent the relevant context and read-only tools.
- Run it manually and inspect the output against the source system.
- Turn the predictable steps into a workflow, with approval before it takes consequential action.
- Compare accepted results, failures, and human time across repeated runs.
We publish reusable code review and shipping skills (opens in a new tab) you can try with your existing agent tools. You can also inspect Valet’s source (opens in a new tab), including the dev-v2 branch used for the architecture described here.
If you have a workflow that keeps needing rescue, or more agent-written work than your team can review, book 30 minutes with me (opens in a new tab). We can look at where the time goes and choose a useful first fix.
