LotsAgent
78% of AI agent projects never reach production. That's the same number we cited earlier this year in the post on what actually goes wrong — and it tracks with the failure pattern we keep seeing across teams: a working demo on day one, a stalled rollout by day thirty, and an agent nobody trusts to run unattended by day ninety.
The gap isn't capability. The agent can do the work. The gap is the missing checklist between "works in a demo" and "runs at 3am with no one watching." That checklist is what kills most rollouts: identity never gets configured, permissions stay wide open, memory is off, durable execution isn't tested, no one ran a 30-minute audit, and the team promotes the agent to unattended before it's earned the right.
This post is the seven-day plan that closes that gap. It takes a first working agent to an unattended production run in one working week, with identity, scoped tools, persistent memory, audit logging, review steps, durable execution, and a final audit built into the timeline. It works because each day produces a working artifact you can verify — not theory, not best practice slides, real checkpoints a real operator can run on Monday morning.
It's not the only way to deploy AI agents. It is the shortest path that doesn't skip the steps that catch 78% of projects at the bottom of the cliff.
Day 1 — Ship a First Working Agent
The goal today is one thing: prove the agent can do the job once.
Pick one workflow. Not five, not the highest-priority workflow in your backlog — the simplest workflow that exercises the agent end-to-end. A good first candidate has three properties: a clear success condition, an external tool it needs to touch, and a real human on the other end of the result.
For most teams that looks like one of these:
- Lead triage: read new inbound, categorize, route to the right person
- Support reply drafting: read a ticket, check account history, draft a response
- Vendor invoice matching: read an invoice email, check it against the books, flag discrepancies
- Meeting prep: read a calendar invite, pull context from the CRM, draft a briefing
Open the Agent Builder and describe what you need in plain English. Don't pre-engineer the prompt. The Builder takes your description and configures the agent's identity, role, goals, and system prompt. You review what it produced. If the framing is wrong, tell the Builder what to change. The no-code AI agent builder pattern covers how this works in more detail — and why you can do it without writing a system prompt by hand.
Connect one tool. The tool you picked is the one you connect. Gmail if it's a triage workflow. HubSpot if it's CRM-driven. Stripe if it's billing. Resist the urge to wire up five tools on day one. One tool, one job, one verification that the agent actually completes the workflow.
Run the agent manually. Trigger it by hand. Watch what it does. Check the output. Confirm the result matches what you'd produce if you did the work yourself.
If it works — even imperfectly — you have a Day 1. If it doesn't, fix the agent, not the workflow. Don't move to Day 2 with a broken foundation.
What's intentionally missing on Day 1: review steps, audit logs, memory configuration, durable execution, scheduled triggers. Those are the next six days. Today is just prove-it-works.
Day 2 — Give the Agent an Identity and Scoped Tools
The goal today is to make the agent accountable before it touches anything important.
By the end of Day 2 the agent has a written identity: who it is, what its job is, what it is not allowed to do, and how it should escalate when uncertain. You write the system prompt that codifies all of this — or refine the one the Agent Builder produced on Day 1. The prompt is the agent's job description. Treat it like one.
Then cut the tool list. Whatever the agent can theoretically do is not the same as what this agent should do for this workflow. Every tool on the list is an attack surface, a failure mode, and a permission boundary. The principle is minimum viable access: the agent gets the tools it needs for the workflow, and nothing else.
Concretely:
- If the workflow is lead triage, the agent gets Gmail (read-only) and HubSpot (read + write to a single lead object). It does not get Stripe, Notion, GitHub, or the calendar. Those tools are not part of this workflow.
- If the workflow is invoice matching, the agent gets Gmail and the accounting API (read-only on the books, write to a single "review queue" object). It does not get the bank API, the payments API, or the customer records.
Remove read/write ambiguity. A tool that lets the agent both read and write a record is a tool that can quietly overwrite something important. Configure the agent's access for each tool as narrowly as the workflow allows. Read-only where the workflow only reads. Write to a specific object where the workflow writes. If the platform's permission model can't express what you need, that's a sign you picked the wrong workflow for an agent.
This is also the day you decide the escalation boundary. What does the agent do when it's uncertain? Does it ask a human, log the uncertainty, or proceed with a default? The answer is documented in the agent's prompt and reflected in the review rules you'll set on Day 4. No surprises later.
By the end of Day 2 the agent has a job description, a tool list scoped to the workflow, and a written escalation policy. Capability has started becoming accountable.
Day 3 — Turn On Persistent Memory
The goal today is to make the agent stop starting cold.
Persistent memory has three layers, and you decide which ones this agent uses. The memory framework covers the full operating model; the short version for Day 3 is:
- Session memory is on by default. The agent remembers what it's doing within a single execution. You don't need to configure this.
- User-specific memory is what the agent knows about the people it works with. The customer who has had three support tickets this month. The lead whose company just raised a round. The vendor who only ships on Thursdays. Turn this on for any agent whose work depends on per-relationship context.
- Agent-specific memory is what the agent learns from its own executions. Which reply template gets the best response rate. Which invoice format the books reject. Turn this on for any agent that does the same kind of work repeatedly.
You also decide what to forget. Memory is not a free storage tier — it's a design choice. The configuration answers three questions:
- What gets stored? Preferences, history, and patterns that improve the agent's work. Not raw message content. Not sensitive payment data. Not stale contact information.
- How long does it persist? Permanent for things that should always be true (the customer's name, the company's billing terms). Expiring for things that go stale fast (the customer's current open tickets). Session-only for things that should not bleed across executions (mid-workflow context, scratchpad reasoning).
- What triggers a refresh? Periodic re-check on key memory types, and explicit re-check before high-stakes actions. If the agent is about to email a customer an apology for a billing issue, it should re-verify the customer's current status, not act on six-month-old memory.
By the end of Day 3 the agent has memory, retention rules, and a refresh policy. It knows what it should know and forgets what it shouldn't. The next run is no longer a cold start.
Day 4 — Add the Audit Layer
The goal today is to make every action the agent takes visible and reversible.
Turn on full execution logs. Every tool call, every decision point, every input and output — captured. The platform should give you a per-execution audit trail: what the agent intended, what it actually did, what each tool returned, how long each step took, and where it succeeded or failed. If your platform can't show you this, you don't have a production system. You have a demo with logging.
Configure review steps for sensitive actions. Not all actions are equal. Some are safe to do automatically. Some need a human eye before they execute. Some should never run at all without explicit human approval. The boundary depends on your workflow and your tolerance for risk. A reasonable default split:
- Auto-execute: Triage, categorization, internal routing, drafting, scheduling, data enrichment, logging
- Human review required: External communications (email, Slack to customers), record modifications, payments, anything that touches a system of record
- Blocked without explicit approval: Anything irreversible — delete operations, account changes, anything that can cost real money or trust
The operating model for accountable automation goes deeper into how to draw this line for your team. The Day 4 deliverable is concrete: every category of action this agent can take has a default disposition. Auto, review, or block. No ambiguity.
Configure alerts for the unexpected. The agent should ping a human channel — Telegram is the right fit in most setups — when it does something outside the expected pattern. The threshold for an alert is "would I want to know about this if it happened at 3am?" If the answer is yes, the alert fires.
By the end of Day 4 every action the agent takes is logged, every sensitive action is gated, and the team has a clear path to know what the agent did, approve what it shouldn't do automatically, and correct what it gets wrong. This is the day the agent stops being a clever script and becomes an operating role.
Day 5 — Make It Durable
The goal today is to make the agent recover from failure without losing its place.
Turn on scheduled or triggered execution. So far you've been running the agent by hand. Today you give it a real trigger — a cron schedule, an inbound email rule, a webhook from another system, a Telegram command. Whatever fits the workflow. The point is the agent now runs on its own schedule, not on yours.
Confirm durable execution is on. This is the infrastructure underneath the agent that checkpoints progress through a multi-step workflow. If a tool fails mid-execution — a network timeout, a rate limit, a downstream service hiccup — durable execution means the agent resumes from the last successful step, not from the beginning. For a lead triage workflow, that means if the CRM call fails on step 3, the agent retries step 3 on its own and picks up from there. The lead doesn't fall through the cracks while you sleep.
The durable execution model covers the underlying mechanics — including why this is the single most common gap in DIY agent setups. The Day 5 deliverable is verifying it's working, not just enabling it.
Run an intentional failure test. Don't trust the marketing. Break the agent on purpose. Pick a tool the agent depends on, simulate a failure (turn off the connection, return an error, exceed a rate limit), and watch what the agent does. The expected behaviour:
- The tool call fails
- The agent logs the failure with full context
- The agent retries according to the configured backoff
- If retries are exhausted, the agent pauses the workflow at the last successful step
- The agent notifies the on-call channel
- When the tool is restored, the agent resumes from the checkpoint — not from the beginning
If any of those steps is missing, fix it today. A workflow that restarts from scratch on every transient failure is not durable. It's a script that sometimes does the work twice.
By the end of Day 5 the agent runs on its own schedule and recovers from failure without losing state. This is the day the agent stops being a thing you babysit.
Day 6 — Run the 30-Minute Audit
The goal today is to look at the agent the way an incoming operator would. With fresh eyes. Pretending you didn't build it. Pretending you're inheriting it from someone who just left.
The 30-minute AI agent audit is the published checklist. Walk through it end to end. The categories are the same every time:
- Identity: Who is this agent? What is it allowed to do? What is it not allowed to do? Where is that written down?
- Permissions: What tools does it have? What can it read, what can it write, what can it delete? Are any of those permissions wider than the workflow requires?
- Memory: What does it remember? How long does each thing persist? What triggers a refresh? Can you see what's stored, and can you delete it?
- Logs: Is every action captured? Is the audit trail complete and queryable? Can you answer "what did the agent do at 2:47am Tuesday" from logs alone?
- Review steps: For each category of sensitive action, is the disposition clear — auto, review, or block? Is the human review path tested?
- Failure modes: What happens when a tool fails? What happens when the agent gets an input it wasn't designed for? What happens when memory is missing? Are those cases handled, or do they fall through to "restart from scratch"?
- Escalation: When the agent is uncertain or something goes wrong, who gets the alert? Is that alert path tested end to end? Does the on-call person have the access they need to step in?
The point of the audit is to find the surprises. The agent that demos perfectly on day one has a dozen things the team didn't think to check. Most of them are small. Some of them are not. Day 6 is the day you find them while you still have time to fix them.
Don't skip steps. Don't optimise the audit away. The whole point is that you do it as if you were seeing the agent for the first time, with the assumption that whoever built it might have missed something. Most teams that do this audit find at least one permission that's too wide, one review step that fires under the wrong condition, or one failure mode the agent handles by silently giving up.
Fix what you find. Re-run the audit. The deliverable for Day 6 is a clean audit pass, documented, with any open issues explicitly waived (with reason) rather than silently ignored.
This is the day you decide whether the agent is ready to go unattended tomorrow. If the audit doesn't pass, it doesn't go unattended. You don't ship what isn't ready.
Day 7 — Go Unattended (Quietly)
The goal today is to give the agent real production hours without giving up oversight.
Start with a 24-hour attended window. The agent runs in production. The team is watching. Logs are checked in real time. The Telegram alert channel is monitored. Every action the agent takes is visible. Nothing the agent does is a surprise, because someone is watching.
The point of the attended window is to catch the things the audit didn't surface. The audit catches design issues. The attended run catches interaction issues — the agent gets an input it wasn't expecting, fires a tool that returns an unexpected response, or hits a corner case the design didn't cover. Real production traffic finds these. Test traffic doesn't.
After 24 hours of clean runs, expand to a 72-hour unattended window with daily log review. The agent runs without a human watching in real time, but the team commits to a daily log review. Every morning, someone opens the audit trail and walks through the last 24 hours. Every action the agent took, every tool it called, every decision it made. The review is a five-minute check at most if the agent is behaving as expected. It's a much longer review if it isn't.
The daily review is not optional. The whole point of unattended operation is that the human attention is amortized — one review per day instead of one per execution. If the reviews don't happen, unattended operation silently degrades into "we hope it works." Don't do that.
Define the on-call path explicitly. When the agent escalates — when it hits something outside its review rules, when a tool keeps failing, when memory is corrupted — who gets the message and what do they do? The path is documented, tested, and rehearsed. The on-call person has the access they need to step in, the documentation they need to understand what the agent was trying to do, and the authority to pause the agent if it needs to be paused.
The EU AI Act compliance frame is worth reading at this stage even if you're not subject to the regulation. It codifies what "human oversight" actually means in an accountable agent system: not a checkbox, but a working escalation path with real authority. Most of what the regulation asks for is just good operating practice.
By the end of Day 7 the agent is running unattended in production. Not because you turned off review — because you earned the right to. The audit passed. The attended run was clean. The on-call path is documented. The reviews are scheduled. This is the day the agent is a production system, not a demo.
After Day 7 — Keep Iterating
The seven days get you to a working unattended run. They don't get you to the best version of the agent. That comes after.
The first month is the calibration period. Review execution logs weekly for the first four weeks. Look for patterns the agent is handling well — those are the places to lock in. Look for patterns the agent is handling poorly — those are the places to fix. Look for the actions that fire review steps the team keeps approving on sight — those are candidates for auto-execution in the next iteration.
Refine the skills. The agent's prompt and tool configuration are not the final version. They're the version that earned the right to run unattended. The next version is the one that runs unattended and gets better at the work over time. The skills get sharper, the review thresholds get tuned, the memory retention gets adjusted.
Add the second workflow only after the first is stable. The temptation is to take the win on day eight and start a second agent for a second workflow. Resist it. Two unstable agents are worse than one stable agent. The first workflow is stable when its daily log review takes less than five minutes and the on-call alerts have stopped firing. Then, and only then, do you start the second workflow — and you start it by reusing the same seven-day plan.
Capability scales after reliability. Every team that skips this order ends up with a portfolio of half-built agents that nobody trusts to run on their own. The 7-day plan is the unit of progress. Repeat it for every new workflow. The second one is faster because you've built the muscle. The third is faster still. By the fifth workflow you have a real production system — not because each individual agent is sophisticated, but because the rollout pattern is repeatable.
FAQ: The 7-Day Production Rollout
What if the agent isn't ready on day 7?
Then it doesn't go unattended. The point of the seven-day plan is the sequence, not the deadline. If the audit on day 6 surfaces real issues, fix them and re-run. The first production hours are not a deadline — they're a gate. Promote the agent to unattended only when it's earned the right.
Do I need a different plan for multi-agent workflows?
The same plan applies, with one adjustment: each subagent goes through its own seven-day rollout. The orchestration layer that connects them is added after each subagent is stable. A triage agent goes through the full plan. A specialist subagent goes through the full plan. Then you wire them together, test the handoffs, and audit the chain. Same discipline, applied per agent.
How is this different from the published production-ready AI agent post?
That post is the theory — what production-ready means, what the architecture looks like, why each layer matters. This post is the operating plan — the seven days, the specific checkpoints, the order of operations. They're complementary. Read the theory first if you're new to the architecture; come here when you need the schedule.
What if my agent workflow is more complex than a single tool call?
The plan still works. The Day 1 "one workflow" should be the smallest end-to-end version of the complex workflow. If the full workflow has five branches and ten tools, the Day 1 version is the simplest branch with the minimum tool set. Get that working, then add branches and tools across the rest of the week. Don't try to ship the full complexity on day one.
Can the 7-day plan run in parallel across multiple workflows?
Technically yes. Practically no, for the first workflow. The plan requires real attention from someone who can review the agent, audit its permissions, test its failure modes, and decide whether it's ready for unattended operation. That attention is the bottleneck. After you've run the plan once, you can run a second instance of it in parallel for a different workflow — but only because the first plan taught you the rhythm. Don't start with parallel rollouts.
What's the most common reason the plan fails?
The audit. Most teams skip the 30-minute audit on day 6, promote the agent to unattended without it, and then act surprised when something goes wrong at 2am. The audit is the gate. Don't skip it. Don't shorten it. Don't decide you've already checked the same things "informally" during the week. The audit is the discipline that turns the rest of the plan into a real production system.
Create your first agent free at lotsagent.com.