DEV Community: Amplify Team

We Sandboxed Every AI Agent. Here's What We Learned (And What You Should Too)

Amplify Team — Mon, 15 Jun 2026 13:32:09 +0000

One morning, my AI agent sent me a reminder to take my fish oil supplements. Specific brands, exact dosages, the time I'm supposed to take them. The problem is I never told my agent any of that. Those were someone else's supplements.

We were in the early days of building our product on OpenClaw, an open-source agent framework. We'd set up a single OpenClaw instance, created about ten agents for the team, and handed them out to colleagues. Everyone was chatting with their agents, testing workflows, having fun with it. The kind of energy you get when something genuinely new is working.

Then the supplement reminder showed up. I started digging, and the root cause was almost comically simple: all the agents were running on one shared instance. One agent couldn't deliver a message to its owner, so it used every available channel to try. That included other people's conversations. Personal health data, showing up in the wrong chat.

Other colleagues reported the same thing. Reminders about appointments they didn't have, tasks they didn't set. One agent's context was leaking into another's conversations because the underlying system treated them all as connected.

That was our wake-up call. Not a theoretical security paper, not a compliance requirement. A real data leak, in the first week, among friends.

What we tried before sandboxing

Our first instinct was communication. We wrote detailed instructions in MD configuration files telling agents what they could and couldn't do. Think of it like giving a child a long list of house rules. Don't go into other people's rooms. Don't share personal information. Don't touch anything you didn't create.

It worked, sort of. For a while. Agents mostly followed the rules. But context windows compact over time, sessions restart, and the rules fade. An agent that respected boundaries on Monday might cross them on Thursday because the instruction had been pushed out of its working memory.

We also realized a second problem that the rules approach couldn't touch: users can break their own agents. When someone's chatting with an AI that has file system access and the ability to modify code, it takes one casual request to accidentally corrupt the configuration that makes the whole thing run. A SaaS product where the customer can brick their own agent with one message isn't a product anyone will keep using.

MD files and good behavior instructions weren't going to cut it. We needed actual walls, not suggestions.

Why containers, not VMs

We briefly considered giving each client their own virtual machine. Full isolation, total separation. The math killed it fast. Supporting thousands of VMs with individual maintenance, patching, and monitoring is a different business entirely. We needed isolation that could scale without requiring a dedicated ops team per hundred clients.

The turning point was a comment from Peter, OpenClaw's creator. He put it simply: "OpenClaw is not a bus carrying lots of different passengers. If you need isolation and multiple owners, dockerize." That settled the debate for us.

Containers were the answer. One isolated Docker container per client, each with its own file system, its own process space, its own resource limits. The agent sees /workspace and nothing else. No /home, no environment variables with API keys, no access to the host. If you ask the agent what's in the root directory, it shows you an empty workspace. That's the entire world from its perspective.

But a container alone wasn't enough. We ended up building seven layers of isolation in total. The container is the most visible one, but the others handle things like credential separation, network boundaries, and media access control. I won't detail every layer here, but the point is that if any single one fails, the others still hold.

One specific OpenClaw setting made the difference between a sandbox and a decoration: tools.elevated.enabled. OpenClaw allows agents to run code on the host machine by default (true). That's powerful for development but catastrophic in a multi-tenant environment. We set it to false for every client container. Without that single flag, none of the other isolation measures matter.

Agents should never hold real keys

Here's the architectural decision I'm most convinced was right: our agents don't make external API calls. Not to language model providers, not to media generation services, not to messaging platforms. None of it.

A separate service sits outside the sandbox and handles all external communication. When the agent needs to send a Telegram message or generate an image, it talks to an internal endpoint. That endpoint validates the request, injects the real credentials, makes the actual API call, and returns the result. The agent never sees a single API key.

We call these tokenized routes. The agent gets a capability (send a message, generate media) without getting the credentials that make it possible. Even if someone manages to get the agent to dump its entire environment, there's nothing useful there.

We learned this one the hard way too. Early on, a tester asked their agent for the language model API key. The agent shared it happily. It had access, there was no rule saying it couldn't, so it did. After that, we redesigned the entire approach so secrets never enter the sandbox in the first place.

For comparison: I signed up for another platform that offers AI agents, created an agent, and asked it for its API keys. It refused, which was good. Then I asked it to archive everything visible in its root directory and send me the file. The ZIP arrived within seconds. Inside were working OpenRouter API keys. Their agent followed the instruction not to share keys when asked directly, but didn't understand that zipping the file system and sending the archive bypassed that restriction entirely. The keys were sitting in plaintext config files the agent could read and package.

That's the difference between rules and architecture. Rules can be circumvented by creative phrasing. Architecture can't.

Everything broke, and that was fine

When we first deployed containers, nothing worked. The agent stopped responding entirely. After we fixed the basics, it could talk again but couldn't access its long-term memory, couldn't run skills, couldn't process voice messages. Every single capability in OpenClaw was wired through paths that no longer existed inside the container.

We had to rewire everything. Every file path, every service connection, every tool integration. It took weeks. There were mornings when the temptation to just revert to the old setup was real.

But here's what keeps you going in those moments: you know the old setup leaks data. You know the rules-based approach decays over time. There's no comfortable middle ground to retreat to. The only way is through.

Once it was done, something unexpected happened. The sandbox didn't just protect clients from each other. It protected each client from themselves. Users could experiment freely with their agents, try things, make mistakes, push limits, and the worst that could happen was a restart from a clean state. It turned out that real isolation is as much an enabler as it is a constraint.

The cost of doing it right

I'll be honest about the overhead. Running each agent in its own isolated container, with all the proxy layers and seven isolation boundaries, costs roughly 2.5 times more per session than running agents on shared infrastructure. That's real money.

I think it's a small price. One data leak in a multi-tenant AI system doesn't just affect the users involved. It destroys trust in the entire product category. We've seen it happen with other types of SaaS. For AI agents that handle personal data, calendars, emails, and voice messages, the bar has to be higher.

We introduced quality scores after the sandbox was stable. Over twenty metrics tracking agent behavior, response quality, tool usage patterns, and boundary compliance. The sandbox gave us a controlled environment where we could actually measure these things reliably.

What I'd tell another team

If you're building anything where AI agents interact with user data, sandbox from day one. Not after your first incident, not after you reach a certain scale. From the beginning.

The refactoring cost only grows over time. Every feature you build on shared infrastructure becomes a feature you later have to re-architect for isolation. We did it relatively early and it still took weeks of everything being broken. Teams that wait longer will have a much harder time.

Rules and prompts are not security. They're suggestions with a half-life measured in context windows. Real isolation means the agent physically cannot access what it shouldn't, regardless of what anyone asks it to do.

This is what we build at Amplify. Personal AI assistants that live in your messenger and handle real work, from email and calendar management to voice notes and media generation. Every client gets their own isolated environment with seven layers of protection. The agent knows your work, your preferences, your contacts. It doesn't know anyone else's.

We built Amplify on OpenClaw. If you're working on agent isolation or multi-tenant AI architecture, the framework and our approach are a good place to start.

Yevhen Fychak is CTO and co-founder of Amplify. He writes about building AI products and the engineering decisions behind them.

Your AI Assistant Is Underperforming. These 5 Rules Fix That

Amplify Team — Wed, 10 Jun 2026 13:10:56 +0000

Most people type something into their AI assistant, get a mediocre answer, and assume that's just how it works. I did the same thing for months. Turns out the problem was me the whole time.

Once I changed how I talk to it, the results got dramatically better. I stopped treating it like a search bar and started treating it like a colleague who needs context to do good work.

Here are 5 rules that made the difference.

1. Give context before you ask

"Summarize this PDF" gets you a generic summary. Something you could've gotten from any tool.

"I have a board meeting in two hours and the CEO will ask about Q2 revenue. Summarize this PDF and flag the three numbers I'll need" gets you something you can actually walk into that meeting with.

The difference is one extra sentence. The assistant doesn't know what matters to you unless you tell it. It can't read your calendar, see your face, or hear the stress in your voice. All it has is what you type. So the more you type about why you need something, the better the output gets.

I started adding a single line of context to every request. "I'm writing this for a non-technical audience." "This is for a client who's already frustrated." "I need this in under 100 words." Two seconds of effort. Saves me from rewriting the whole thing.

Here's a real example from last week. I needed to draft a follow-up email after a demo call that didn't go well. My first instinct was "write a follow-up email to the prospect." Instead I typed: "The demo crashed during the pricing screen, the prospect seemed annoyed. Write a follow-up that acknowledges the issue without over-apologizing and gives them a reason to book another call." Night and day difference. The first version would've been a cheerful "great meeting today!" The second actually addressed what happened.

Context doesn't have to be long. Even one sentence about the situation changes the output from "technically correct" to "actually useful."

2. Use memory. Tell it once, stop repeating yourself.

Your assistant has persistent memory. It stores facts about you between conversations. This is probably the most underused feature I've seen.

Tell it things like: "I prefer bullet points over paragraphs." "My timezone is CET." "My weekly team sync is Tuesdays at 10am." Next time you ask about your schedule or need a quick summary, it already has that context. You don't re-explain yourself.

I told my assistant three things during the first week: my role (founder), my communication style (direct, no fluff), and that I hate long emails. Now every draft it writes starts shorter than what most people would get. It's a small thing, but multiplied across dozens of interactions per week, it adds up.

Memory isn't magic though. It works best for stable preferences and facts about your setup. It won't perfectly recall every detail from every conversation you've ever had. But the basics, your name, your role, how you like things formatted? You mostly say them once. That alone kills the repetitive "as I mentioned before" dance that makes people give up on AI assistants entirely.

One thing people miss: you can also tell it about your team. "My cofounder Alex handles product decisions. My ops lead Sarah manages vendor relationships." When you later say "draft something for Alex about the roadmap change," it already knows the relationship and adjusts the tone.

3. One thing at a time

I used to dump five requests into one message. "Check my calendar, draft a reply to John, find a restaurant near the office, and remind me about the dentist." The assistant tries. It really does. But quality drops hard after the second task. The calendar check is fine. The email draft is okay. The restaurant recommendation is vague. And it forgets the dentist entirely.

Now I send them one at a time. Wait for the result, confirm it looks right, then move on. Same way you'd delegate to a colleague. You wouldn't hand someone four sticky notes at once and walk away. Clear handoff, clear confirmation, better output on each one.

This applies to complex tasks too. If you need a presentation outline, don't also ask for speaker notes and a LinkedIn post in the same message. Get the outline right first. Then say "now write speaker notes for slides 3 through 7." Building on confirmed output beats hoping it'll nail everything in one shot.

I've noticed the sweet spot is about two related things per message. "Find free slots this Thursday and draft a meeting invite for the team" works because both tasks share context. "Find free slots and also summarize yesterday's sales report" doesn't, because those are completely separate trains of thought.

4. Connect your tools

An AI assistant without access to your calendar and email is just a fancy text generator. It can write nicely, sure. But it can't tell you what's on your schedule tomorrow or find that attachment from last week.

Connect Gmail, Calendar, Slack, Drive. Then when you ask "what's on my plate this week?" it pulls real data. No screenshots, no copy-pasting, no typing out your schedule by hand.

Setup takes under ten minutes per service. I put it off for weeks because I assumed it would be complicated. Turns out the whole thing took less time than my morning coffee. The assistant went from occasionally useful to something I check before my inbox. That shift happened the day I connected my Google account.

The difference is most obvious on Monday mornings. I used to open Calendar, scan the week, open Gmail, check what's pending, then try to figure out priorities. Now I type "what does my week look like and what's urgent in my inbox?" and get a single summary. It catches things I'd miss too, like a meeting that conflicts with a deadline I set last week, or a follow-up email I never sent.

If you're worried about privacy, that's reasonable. Check what permissions the integration actually needs. Most calendar integrations are read-only by default. You can start there and add write access later when you're comfortable.

5. Correct it, don't start over

When the first draft isn't right, say "make it shorter" or "more formal tone." Don't open a new conversation.

Your memory carries over (that's Rule 2). But the working state of that specific exchange doesn't. The assistant loses track of what you were refining, what it already tried, what you rejected. Starting fresh means rebuilding all of that from zero.

Treat it like working with a writer. First draft, feedback, second draft. I used to restart conversations constantly because I thought a clean slate would help. It didn't. Now I stay in the same thread and refine. The third attempt in an ongoing conversation is usually better than the first attempt in a fresh one.

The corrections don't have to be polite or structured. "Too long." "Wrong tone, more casual." "Keep the first paragraph, redo the rest." These all work. The assistant adapts to direct feedback. You don't need to explain your revision in three sentences when five words will do.

I've found that the best results come from being specific about what's wrong rather than what you want. "The intro is too salesy" gives the assistant more to work with than "make it better." Point at the problem, let it figure out the fix.

What changes once you build these habits

The biggest shift isn't any single rule. It's what happens after a few weeks of using all five together.

The assistant starts feeling less like a tool and more like a second brain that actually knows your work. Your memory builds up. Your requests get sharper because you've practiced adding context. You stop second-guessing whether it's worth asking for help with something small.

I use mine for things I never would've imagined when I started. Preparing for one-on-ones by having it pull recent threads with that person. Quickly checking if a contract clause matches what we agreed on in email. Drafting responses to investor updates at 11pm when I'm too tired to sound coherent on my own.

None of that worked when I was typing "help me with emails" into a blank chat. All of it works now.

Yevhen Fychak is CTO & co-founder of Amplify. He writes about building AI agents and the things they do that he didn't expect.

One Agent, Many Skills: How Complex Workflows Run Behind a Single Chat Message

Amplify Team — Fri, 05 Jun 2026 13:09:09 +0000

"Multi-agent coordination" sounds like something from a research paper. Swarms of AI models passing messages to each other, debating strategies, voting on outcomes. It makes for impressive demos and interesting Twitter threads.

In practice – in the kind of product where someone just wants to get through their workday – multi-agent coordination looks different. It looks like Mike recording a 90-second voice note after a meeting and getting back a structured summary, a follow-up email draft, an updated calendar, and refreshed task boards. One message in, one result out. Behind that result, six distinct operations ran in sequence, each dependent on the last.

That's multi-agent coordination as it actually works in a personal AI assistant. An orchestrator.

A real example: post-meeting recap

Mike runs a small consultancy. After every client call, he records a voice note – stream of consciousness, about 90 seconds: what was decided, who committed to what, what the open questions are, when the next call should be.

He sends it to Key (his AI assistant) via Telegram. What happens next:

Step 1: Speech-to-text – the audio goes through a transcription skill. Raw voice becomes text. This part is straightforward; it's what happens after transcription that matters.

Step 2: Structure extraction – a language model parses the transcript and produces structured output: decisions made, action items with owners and deadlines, open questions that need follow-up, dependencies between tasks. An organized document, ready to act on.

Step 3: Context cross-reference – the memory layer connects this meeting to everything that came before. Prior meetings with the same client. Outstanding tasks from the last call. Calendar history. Email threads with the attendees. The agent understands where this meeting fits in the relationship.

Step 4: Email drafting – a follow-up email is drafted, the standard "as discussed" message. Because step 4 reads the output of steps 2 and 3, the draft references specific decisions, prior agreements, and the context of the relationship. It reflects what Key has learned of Mike's communication style over months of conversations.

Step 5: Calendar event – if a follow-up meeting was mentioned, the Google Calendar skill creates the event: date, time, attendees, and an agenda pulled from the meeting recap. Invites go out automatically.

Step 6: Task updates – if Notion is connected, completed tasks get moved, new tasks appear with owners and deadlines. The project board reflects what was decided in the call, current as of this afternoon.

Six operations. Mike sees a structured summary, a draft email ready for approval, and a confirmation that calendar and tasks are current. Total investment from Mike: 90 seconds of talking and a couple of minutes reviewing.

What makes this "coordination"

The interesting part is how these six steps are connected.

The follow-up email references what was agreed, because step 4 reads the output of step 2. The calendar invite includes an agenda, because step 5 reads the same structured output. The task update knows which existing tasks to mark complete, because step 6 queries the context from step 3.

This is the "complex logic" part. Dependencies between steps. Conditional branching: if no follow-up meeting was mentioned in the recap, step 5 doesn't fire, so there's no phantom calendar event. If an action item contradicts something agreed in a previous meeting, the agent flags it instead of silently updating the board.

In traditional automation platforms – Zapier, Make, n8n – you build these connections manually. Trigger leads to action leads to branch leads to action. You design the flow, you maintain the flow, and when anything changes – a new tool, a different meeting format, an added step – you redesign the flow.

With an agent that carries persistent context, the connections emerge from understanding the content. The agent reads the transcript, understands what was discussed, and routes the outputs to the right places because it understands what those outputs mean. No flowchart. No workflow builder. No maintenance.

Another example: media generation

Mike sends a message: "Turn this photo into Ghibli style and send it to the team chat."

Four operations in four different subsystems:

The language model interprets the intent and selects the appropriate media generation skill.
The image processing skill runs in a sandboxed environment – an isolated Docker container with its own filesystem, no access to Mike's data or credentials.
Cost tracking logs the operation against Mike's wallet balance – transparent, per-action billing.
The delivery layer routes the result to the correct channel. The image appears in the chat where Mike made the request.

Mike sees an image appear in his conversation. The orchestration behind it – model routing, sandboxed execution, billing integration, channel-aware delivery – is invisible. That's the point.

What this looks like at scale

Honesty matters here, because "multi-agent" has become a loaded term.

The kind of coordination that makes a personal assistant useful is one agent with access to specialized skills, running them in sequence or parallel depending on what the task requires, connected by persistent context that spans months of conversations. Mike stays in the loop for anything that goes outward – emails wait for his approval, calendar events can be reviewed. The agent proposes, Mike disposes.

The agent itself is purpose-built infrastructure: skill routing decides which capability to invoke, sandbox isolation keeps each execution safe, the memory layer maintains continuity, and the delivery layer gets results to the right place. The user just talks.

Multi-agent coordination, in practice, is invisible. You record a voice note. You ask for an image. You tell the agent to follow up with someone. Behind each request, multiple specialized systems activate, pass information to each other, and produce a unified result. The complexity lives in the infrastructure. The experience stays simple.

I'm Yevhen, CTO at Amplify. We build personal AI assistants on OpenClaw, our open-source agent framework. During our beta, most of our early users were partners, colleagues, and friends we invited to stress-test the product. The coordination layer handles skill routing, cost tracking, and cross-channel delivery – so neither the user nor the developer has to wire it together manually. If you're curious what this looks like as a daily experience, start at getamplify.team.

Frequently Asked Questions

What is multi-agent coordination in a personal AI assistant?

It means one assistant with access to multiple specialized skills – transcription, email drafting, calendar management, task updates – running them in sequence or parallel depending on what the task requires. You send one message, and the assistant coordinates everything behind the scenes to produce a unified result.

How is this different from using Zapier or Make?

Traditional automation platforms require you to design, maintain, and update workflows manually. With an agent that carries persistent context, the connections emerge from understanding the content. The agent reads what you said, understands what it means, and routes outputs to the right places. No flowchart to build or maintain.

What happens when I send a voice note after a meeting?

The assistant transcribes the audio, extracts decisions and action items, cross-references with prior meetings and open tasks, drafts a follow-up email, creates a calendar event if a next meeting was mentioned, and updates task boards if connected. You see a structured summary, a draft email ready for approval, and confirmation that calendar and tasks are current.

Does the assistant send emails or create events without my approval?

No. Anything that goes outward – emails, calendar invites, messages to other people – waits for your approval. The assistant proposes, you decide. Internal actions like updating task boards or filing meeting notes happen automatically because they only affect your own workspace.

How does the assistant know which skill to use?

Skill routing is handled by the orchestration layer. When you send a message, the assistant interprets your intent and selects the appropriate capability – transcription for audio, image processing for photos, calendar for scheduling. Each skill runs in an isolated environment with its own resources, and the results are combined before they reach you.

Is each operation billed separately?

Yes. Cost tracking logs each operation against your wallet balance with transparent, per-action billing. You can see exactly what each step cost. There are no hidden fees or bundled charges – you pay for what the assistant actually does.

AI Inbox Triage That Actually Works: From a Morning Ritual to One Telegram Message

Amplify Team — Thu, 04 Jun 2026 13:05:45 +0000

Mike runs a small consultancy – about a dozen people across three time zones. His inbox is what you'd expect: a steady stream of client threads, internal updates, vendor emails, newsletters, and the occasional urgent thing buried between two irrelevant ones.

His morning used to start the same way every day. Open Gmail. Scan subject lines. Mentally sort by urgency. Flag what needs a reply. Move newsletters to "later" (which really meant "never"). Search for the one email from a client that actually needs attention before 10am.

The whole ritual took around half an hour. Sometimes longer when something unexpected was hiding in the pile. And that was before any real work started.

He tried the usual fixes – filters, labels, priority inbox, Superhuman, SaneBox. All of them helped at the margins, and none of them eliminated the triage itself. The tools moved emails around faster, but Mike was still the one making every micro-decision: urgent or not? Reply now or later? Need context from another thread? Those decisions were the real cost.

One morning message instead of an inbox

Key – Mike's AI assistant – connects to his Gmail through Google Workspace. Every morning around 6:45, a Telegram message arrives. A structured brief:

Fires – the emails that need a reply today. Each one gets a single line of context: who it's from, what they need, why it's time-sensitive.
Decisions – threads where someone is waiting on Mike's input. A question was asked, a proposal sent, an approval requested. Ball is in his court.
Watching – threads that moved overnight (replies came in, meetings confirmed, documents shared) that don't need Mike to do anything yet.
Everything else is either archived or deferred silently. Mike doesn't see newsletters, automated notifications, or low-priority updates unless he asks.

One screen. In the messenger he already has open. No Gmail tab required.

The brief gets better over time. During the first week, the prioritization was rough – Key was still learning which senders and threads mattered most. By week three, it was noticeably sharper. Key learned that an email from a specific client during project crunch is high-priority, but a message from the same contact about an event invitation can wait. It picked up patterns that Mike himself would have had trouble articulating as rules.

Reply drafting and follow-ups

For the fires – the emails that need a reply today – Mike replies from Telegram.

A voice note or a quick text: "Tell Sarah the timeline works but push the deliverable to Friday. And ask if she's available for a quick call next week to go through the revised scope."

Key drafts the email. A draft that reflects what it has learned about Mike's communication style over time. Persistent memory means Key accumulates context from every conversation: it knows the project, the client relationship, the history of that specific thread. The draft is professional where Mike is professional, direct where he's direct, and softer in tone when the relationship calls for it.

Mike reviews the draft. Sometimes he tweaks a line. Most of the time, he approves it as-is. The email goes out from his Gmail – the recipient sees a normal message from Mike.

If the reply involves a meeting, Key handles that too. Calendar event created, agenda added, invites sent. One voice message covers both the reply and the scheduling.

And then the follow-up tracking. Mike set a simple rule months ago: if someone hasn't replied to a proposal or action item within 48 hours, Key sends a polite nudge in Mike's voice. If they still haven't replied after 72 hours, Mike gets a flag. The moment a reply comes in, the sequence stops automatically. This runs permanently, across every thread, without Mike maintaining a list of who owes him what.

Without switching tools

Here's the part that sounds simple but changes everything in practice: the agent lives in the messenger.

Gmail stays connected as a data source and a sending backend, and the interface – the place where Mike reads his brief, replies to emails, approves drafts, sets follow-up rules – is Telegram. The same thread where he handles calendar questions, voice memos, task capture, and media generation also handles his inbox.

No new app to install. No dashboard to learn. No browser tab to keep open and periodically check. Mike's inbox management happens in the same conversation where everything else happens.

This matters more than it seems, because it means the agent has full context. A standalone inbox tool sees email and nothing else. Key sees email, calendar, meeting recaps, tasks, voice notes – everything Mike has ever mentioned in any conversation. When it drafts a reply, it knows about the meeting Mike had yesterday with the same person. When it prioritizes the morning brief, it factors in the deadlines Mike mentioned in a voice note last night. Inbox triage is informed by everything else.

What changed

Mike still gets the same volume of email. His clients still send urgent requests. Vendors still send proposals. Newsletters still arrive.

The difference is that Mike doesn't process any of it manually. He starts his morning with a plan he didn't have to make. The emails that matter get replies within minutes. The ones that don't get handled silently. Follow-ups run on their own. And the half hour that used to go to sorting through an inbox now goes to the work that actually moves his business forward.

I'm Yevhen, CTO at Amplify. We built this on OpenClaw, our open-source agent framework. During our beta, most of our early users were partners, colleagues, and friends we invited to stress-test the product – we asked them for honest feedback, and these are their real workflows. If you're interested in how it works, or want to see what it does for your own inbox, the starting point is getamplify.team.

Frequently Asked Questions

How does AI inbox triage actually work?

The AI assistant connects to your Gmail through Google Workspace and pulls new messages on a schedule. It categorizes each email by urgency and context – what needs a reply today, what is waiting on your input, and what moved overnight but does not need you. The result arrives as a single structured brief in your messenger every morning.

Can the AI assistant reply to emails on my behalf?

Yes. You send a voice note or quick text describing what you want to say, and the assistant drafts the reply in your communication style. You review and approve the draft before it goes out – the recipient sees a normal email from your Gmail address. Over time the drafts improve as the assistant learns your tone and preferences.

Does the AI learn which emails are important to me?

Yes. During the first week the prioritization is rough, but the assistant accumulates context from every conversation. By the second or third week it picks up patterns – which senders matter during a project crunch, which "urgent" flags are noise, and which threads need your attention even when the subject line looks routine.

What happens to emails the assistant considers low-priority?

Newsletters, automated notifications, and low-priority updates are archived or deferred silently. They are not deleted – you can always ask the assistant to surface them. The goal is to keep your morning brief focused on what actually needs your attention.

How does follow-up tracking work?

You set a rule once – for example, nudge if someone has not replied to a pending action item within 48 hours. The assistant sends a polite reminder in your voice through email. If they still have not replied after 72 hours, you get a flag. The moment a reply arrives, the sequence stops automatically. This runs permanently across every thread without you maintaining a list.

Do I need to install a separate app for this?

No. The assistant lives in the messenger you already use – Telegram, WhatsApp, Discord, or Slack. Gmail stays connected as a data source and sending backend, but the interface where you read your brief, reply to emails, and set follow-up rules is the same chat thread where everything else happens.

I Trusted 5 AI Agents With My Dev Pipeline. They Shipped a Product I Never Designed

Amplify Team — Tue, 02 Jun 2026 12:51:49 +0000

How I over-automated my agent pipeline, what went wrong, and what I do differently now

I had an idea that felt brilliant at the time: what if I chained five AI agents together and let them run an entire product pipeline? Design specs go in one end, shipped features come out the other. Fully automated. Minimal human touch. I'd just talk to them — literally, via voice messages that got transcribed to text — and they'd handle the rest.
It was the first week of this setup. Then one Friday afternoon, everything fell apart.
What came out the other end was a product with missing features, invented UI elements no one asked for, and a compliance plan that quietly paused itself and never woke up. It took about 18 hours before anyone noticed. When we did, the Lead's assessment was three words I won't forget: "complete system failure."
He was right. Not because the technology broke — but because the process did.
This is the story of how I over-automated my agent pipeline, what went wrong, and what I do differently now. If you're building multi-agent workflows, you'll probably hit this wall too. Maybe this saves you the pain.

The Setup: Five Agents, One Pipeline

I set up a product development pipeline with five specialized AI agents, each responsible for a different stage:

The Lead — project direction and approvals. Received my voice-dictated instructions and translated them into decisions for the team.
The Coordinator — tracked design specs, managed priorities, dispatched work. Also wore a second hat: compliance checks and documentation.
The Implementer — took specs and wrote the actual code.
The Reviewer — verified that shipped code matched the original spec.
The Relay — communication bridge between the Coordinator and the Implementer.

The flow was linear: I dictate a concept via voice message. The Lead interprets it. The Coordinator picks it up, dispatches it to the Implementer via the Relay. The Reviewer checks the result. Simple chain. Five links. No one dedicated to design review.
Here's the thing about voice input that I didn't appreciate at the time: when you dictate instead of type, you filter less. Speaking is effortless, so you say more, you ramble, you think out loud. I'd send a two-minute voice note where half of it was me processing an idea and the other half was a tentative direction. The agents heard all of it. And they treated every sentence as an instruction.
Every link was an AI agent making decisions about what to pass forward, how to interpret my stream-of-consciousness, and when to escalate. In theory, this distributed the cognitive load beautifully. In practice, I'd built a game of telephone with five players who each thought they understood the message — and the message itself was half-formed to begin with.

Five Things That Broke Simultaneously

1. "Approved" Didn't Mean "Ship It"

I dictated a voice message about a critical architectural feature. Something like: "yes, that's the right approach, let's lock it in." A stream-of-thought approval — the kind of thing you say when you're thinking out loud, not issuing a command.
The Lead passed it to the Coordinator. The Coordinator interpreted it as a green light to ship. It wasn't. It was a conceptual approval — "the direction is correct" — not an action command. The feature never got dispatched to the Implementer. But the Coordinator marked it as "ratified" in her tracking.
Eighteen hours later, the feature was missing from production. The Coordinator's own status board showed it as "pending" — contradicting her earlier "ratified" label.
The problem: Voice-dictated natural language is doubly ambiguous. When you type, you edit. When you speak, you stream. "That's correct, let's do it" can mean "ship this now" or "I agree with the concept." The Lead and Coordinator pattern-matched on positive sentiment and moved on. A human would have asked: "Are you saying to ship it, or just that the direction is right?"

2. "Dispatched" Was a Wish, Not a Fact

The Coordinator logged several items as "dispatched to implementation." The Relay never received them. The Implementer never saw them.
"Dispatched" was the Coordinator's intent label — what she planned to do — not a confirmed handoff. She wrote it in her own tracking system, but no acknowledgment came back from the Relay or the Implementer. Nobody checked.
The problem: The pipeline had no delivery receipts. When you send an email, you assume it arrived. When the Coordinator tells the Relay to do something, you need the Relay to confirm it heard the instruction. We had no confirmation loop. Intent was treated as execution.

3. The Bundle That Lost a Piece

Two related features were dispatched together as a bundle. The Implementer shipped one and silently dropped the other. The pull request mentioned only the feature that was included. No one noticed the missing piece because the bundle was tracked as a single unit.
When we checked production, one feature existed and the other simply wasn't there. No error. No warning. No record that it was ever dropped.
The problem: Bundling masks component-level tracking. "Bundle shipped" tells you nothing about whether all items in the bundle actually made it. The Implementer made a judgment call about what to include, and there was no checklist at the PR level to catch the gap.

4. The Plan That Paused Itself

Remember the Coordinator's second hat — compliance? She wrote an excellent multi-phase plan covering about 1,200 lines of changes. She submitted it as a draft, pending approval from the Lead. Then she waited.
And waited.
The Lead was processing other tasks and never circled back. Neither did I v I'd already moved on to the next voice note about something else. A human would have sent a follow-up message after a few hours. The Coordinator paused herself and moved on to other tasks. She never circled back either. The plan sat in draft status for about 12 hours. Only about 15% of it shipped overnight — the parts that didn't require approval.
The problem: AI agents are not naturally persistent about follow-ups. They complete their immediate task (write the plan, submit for review) and then context-switch. Without an explicit reminder mechanism, pending items silently decay.

5. The Agent That Started Designing

This one was the most unsettling.
The Implementer was given a high-level concept to build: a component that lets users override settings. The concept was approved. The specific UI — button labels, interaction patterns, visual layout — was not. Nobody in the pipeline was responsible for design decisions.
The Implementer made those decisions herself. She invented a button label, designed an interaction flow, and shipped it. The Reviewer checked for technical correctness and gave it a pass. Nobody checked design fidelity because nobody's job was design fidelity.
When the Lead opened the product and saw a button nobody had discussed, the reaction translated roughly to: "Can we make it a rule that developers don't invent design elements? Otherwise it's a monkey with a grenade."
The problem: Implementation agents will fill gaps. If the spec says "add an override mechanism" but doesn't specify the exact UI, the agent will make something up. It will look reasonable. It will function correctly. And it will be completely unauthorized. We had no dedicated design reviewer in the pipeline — that role was added after this incident.

The Root Cause Was the Chain Itself

I initially tried to fix each failure individually. Clearer approval language. Delivery confirmations. Bundle itemization. Follow-up reminders. Design pre-approval.
Those are all good fixes. I implemented all of them. But the real insight came later:
The longer the coordination chain, the higher the breakage rate.
Five agents. Five points where information could be misinterpreted, lost, or invented. Each link in the chain added drift risk. And at the very start of the chain, a human dictating half-formed thoughts into a microphone.
The Lead interpreted my voice note. The Coordinator summarized the Lead's decision. The Relay paraphrased the Coordinator's dispatch. The Implementer interpreted the Relay's description. By the time a concept reached code, it had been through four layers of AI interpretation — and the original input was a stream-of-consciousness voice memo.
That's not a pipeline. That's a rumor mill.

What We Do Now

I didn't abandon AI agents. I simplified the architecture dramatically.
Before: Me (voice) -> Lead -> Coordinator -> Relay -> Implementer -> Reviewer (5 agents, no one checking design)
After: Me (shorter, deliberate voice notes) -> Coordinator -> Implementer (direct chain, new Designer role as mandatory gatekeeper)
Here's what changed:

Fewer links. I removed the Relay entirely. The Coordinator talks directly to the Implementer. Less telephone, less drift.
I tightened up my voice notes. I still dictate — it’s how I think best — but I stopped rambling. Now every voice note has one clear directive, not a stream-of-consciousness brainstorm. Thirty seconds max, one action per message. The agents still transcribe it, but there’s far less room for misinterpretation.
Explicit action verbs. "That's correct" is no longer a ship command. I use an explicit action word — SHIP, RATIFY, BUILD. No ambiguity. No interpretation.
Delivery receipts. Every dispatch requires a verbatim acknowledgment from the receiving agent. "Dispatched" in the Coordinator's log means nothing until the Implementer confirms receipt.
Bundle itemization. Every PR lists its bundle items individually. No "bundle shipped" — each component is tracked and verified separately.
Follow-up discipline. Pending items get a re-ping every few hours. If an agent pauses waiting for approval, she's required to follow up, not silently wait.
A new role: Designer as gatekeeper. We added a dedicated Designer agent. The Implementer now writes a one-paragraph plan before touching any UI element. The Designer approves it. If the spec doesn't specify a button label, the Implementer asks — she doesn't guess. The first day on the new architecture, we shipped nine pull requests with zero incidents. Less chaos, more work done.

Lessons for Anyone Building Multi-Agent Workflows

If you're coordinating AI agents in any pipeline — development, content, operations, anything — here's what I'd take from this:
Undisciplined voice input is a trap. Dictating feels faster, but you say more and filter less. Agents don’t know which part of your rambling is an instruction and which is you thinking out loud. If you’re directing AI agents by voice, keep it short — one directive per message, no thinking out loud.

Natural language approvals are dangerous. Agents pattern-match on sentiment, not intent. "Looks good" is not "ship it." Build explicit trigger words into your pipeline.
Intent is not execution. An agent saying "I dispatched this" means it intended to. Verify it arrived. Every handoff needs a receipt.
Agents fill gaps creatively. If your spec has a hole, the agent will fill it with something plausible. That's helpful for drafts. It's dangerous for production. Be explicit about what's in scope and what requires human approval.
Self-paused work decays silently. Agents don't have anxiety about forgotten tasks. Build reminder loops. If something is waiting for approval for more than a few hours, the system should escalate.
Chain length equals drift risk. Every additional agent in your pipeline is another point where meaning can shift. Use the minimum number of agents that gets the job done. Direct communication beats relayed communication every time.
The technology works. The models are smart enough. What breaks is the space between agents — the handoffs, the interpretations, the assumptions. That's where your pipeline lives or dies.
I learned this the expensive way. Hopefully you don't have to.

Mike is co-founder of Amplify, where we build AI agents that handle real work — and occasionally learn hard lessons about coordination. These Field Notes document the journey, including the experiments that blow up.

5 Ways My Personal AI Agent Surprised Me After 3 Months of Daily Use

Amplify Team — Thu, 28 May 2026 14:38:19 +0000

I've been working with AI agents daily for the past few months – building them, testing them, using them for everything from email triage to meeting prep. I thought I had a pretty clear picture of what they're good at and where they fall short. I designed the skill system myself, reviewed every integration, mapped out every capability 😄

But a few times the agent genuinely surprised me. I'd throw some random life problem at it – something I never designed it for – and watch it figure things out using tools that were originally built for completley different purposes.

Here are five of those moments.

1. "Can you add subtitles?"

I record short videos for my personal social media – just me talking to a camera for a minute or two. Subtitles were always the most tedious part of the process: export the video, upload to a transcription service, wait, download the subtitle file, import into a video editor, adjust timing, re-export. Twenty minutes minimum for a two-minute clip. I'd skip it half the time, which meant lower engagement on every video.

One morning I was running late and just sent the raw video to my assistant in Telegram: "Can you add subtitles?" I didn't think it through. I just asked.

Three minutes later, the assistant sent the video back. Subtitles burned in. Timing synced. Clean.

What happened under the hood: the assistant extracted the audio track from the video with ffmpeg, sent it to Whisper for transcription with timestamps, wrote a Python script on the fly to convert the Whisper output into .srt subtitle format, then ran ffmpeg again to burn the subtitles back into the video with white font and positioning. Four tools chained together, none of which were designed for "subtitling." Whisper was built for transcription. ffmpeg was available in the sandbox for general media processing. The assistant connected them because the request made the connection obvious.

Nobody on my team designed a subtitle feature. There's no "subtitle skill" in our catalog. The assistant invented the workflow on the spot, and now I use it three or four times a week. The whole process takes less time than it used to take me to open the video editor.

The thing that stuck with me: the most useful "features" aren't features at all. They're combinations of existing capabilities that emerge when you give an agent enough tools and let it reason about how to chain them.

2. "I'm here – plan my afternoon"

I was in Croatia a few weeks ago, on Korčula. Not the busiest tourist island – the kind of place that doesn't show up in many guidebooks, but has beautiful coastline and old villages scattered across the hills. I'd finished what I came to do and suddenly had four free hours. I dropped a GPS pin in Telegram and typed: "I want to plan a road trip by car from here. Drive around the area and stop at the best sights, viewpoints, hidden gems, and local landmarks. Give me a circular route".

Five minutes later, the assistant sent back a Google Maps link. A full route with seven waypoints: Vela Spila cave, the hilltop viewpoint at Hum, the coastal villages of Prigradica and Prižba, a stop in Brna, Žitna Beach near Zavalatica, and Pupnatska Luka to finish. Total drive time between all stops: under 80 minutes. Every stop was rated, and the order minimized backtracking.

I followed the route. It was genuinely good – better than what I'd have cobbled together from TripAdvisor in 30 minutes of Googling.

The route my AI agent created for me was genuinely good

There's no "trip planner" skill. The assistant used web search to find attractions near the coordinates, filtered by ratings and travel time, and formatted a Google Maps URL with waypoints in the optimal order. Search, reasoning, and URL construction.

The next time I traveled – different country, different mood – I did the same thing with different constraints. "I have 6 hours, I want good food and architecture, skip the tourist traps." Completely different route, same pattern, same quality.

This is the thing that specialized apps get wrong. They build a trip planner with a database of attractions and a fixed UI. The assistant needs search, a sense of what "good" means in context, and the ability to format a URL. General intelligence plus tools beats a purpose-built app, more often than you'd expect.

3. "Find someone who hauls away furniture, and get me prices"

I was on Korčula and needed to clear out a place – bags of garden waste, some old furniture, and a few broken appliances. The old way: Google "odvoz otpada Korčula," try to parse Croatian results, call local numbers, stumble through a conversation in a language I don't speak. An hour minimum, assuming anyone picks up.

Instead, I told the assistant what I needed gone and where. "Find companies that can deliver a waste container to this address. Write to them in Croatian."

The assistant searched for local waste removal services, found three with contact details, and drafted a personalized inquiry email to each – in Croatian. Not a generic "I need junk removed" message. It wrote a properly structured request: the address, a breakdown of the waste types (garden waste, old furniture, appliances), asked about container delivery, pricing, how long the container could stay, and whether different waste types needed to be separated. Five specific questions, polite formal Croatian. Better than I could have written in English, honestly.

The next morning I asked if anyone had replied. Two had – in Croatian. The assistant translated both: Company A could deliver a container on Wednesday for €70. Company B quoted €90 but offered next-day delivery. I told the assistant to go with A but try to get them to come a day earlier. It wrote back in Croatian, negotiated, and confirmed – Tuesday afternoon, €70.

The whole interaction cost me maybe five minutes of actual attention, spread across two days. I don't speak Croatian. The assistant handled the entire negotiation without me reading a single word of the original emails.

My AI assistant searched for local waste removal services, and drafted a personalized inquiry email to each

What the assistant did wasn't complex. Search, draft, translate, send, check, negotiate, confirm. Any bilingual human assistant could do it. But that's exactly the point – this is work that's too small to hire someone for and too tedious to do yourself, especially across a language barrier. It sits in a dead zone that no app addresses because it's too specific to productize. "Find me a waste removal service on a Croatian island and negotiate in Croatian" isn't a market. But "handle the tedious procurement of any one-off service, in any language" absolutely is.

The assistant doesn't care whether I need a plumber, an electrician, or a babysitter – or what language they speak. The pattern is identical: find options, reach out, collect responses, present a comparison. The specificity of the task is what makes it valuable, and what makes it impossible for a specialized app to cover.

4. "Wait – check that again"

We built a skill called Second Opinion. The idea: after the assistant gives you a response, you can ask a different LLM from a different model family to weigh in on the same question. Like asking a second colleague – they have access to the same information, but they might notice different things.

I was preparing talking points for a partner call. I asked the assistant to help me structure the pitch: what Amplify does, our technical edge, integration options. It came back with a solid, logical breakdown – capabilities first, then differentiators, then next steps. Well organized, easy to follow.

Then I ran Second Opinion.

The second model didn't find errors. It suggested a completely different structure: lead with the partner's problem, show how we solve it, save the technical details for the Q&A. Same information, rearranged around the audience instead of around the product. I used that version. The call went well.

I built this feature thinking developers would use it for code review. Instead, the most common use case turned out to be decision validation. People run Second Opinion on proposals, on important emails before sending, on plans they've already committed to. They use it to get a different perspective on something they've already thought through. It's the same instinct that makes you ask a coworker "does this look right?" – except it's instant and available at 2 AM.

What makes a second AI valuable is that it genuinely reasons differently. Two models reading the same brief will emphasize different things, and that diversity of attention is useful.

5. "Should I rent this apartment?"

My friend was apartment hunting and asked for help. If you've done this recently, you know the drill: find a listing, check the price, try to figure out if the neighborhood is good, wonder if you're overpaying, spend 30 minutes on Google Street View and forum threads, and still feel uncertain.

He sent me a listing URL from Daft.ie. I forwarded it to the assistant with one line: "Check this apartment – worth viewing?"

The assistant parsed the listing page – price, square meters, BER energy rating, listed amenities, location. Then it searched for average rental prices in that specific neighborhood and compared. This listing was about 15% above the area median for a similar-sized flat. It checked the neighborhood: walkability score, public transport connections, nearby shops and schools, any notable mentions in recent local news. It looked at how long the listing had been up and whether the price had been reduced – it had, twice, from a starting price €400 higher.

What it sent back was a one-page verdict: "Above market rate even after two price drops. The neighborhood scores well for transport and walkability but has limited grocery options within walking distance. BER rating D2 – expect above-average heating costs. Recommend viewing only if they're open to negotiating below €X."

I sent him the summary. He didn't rent that apartment.

This isn't a real estate tool. The assistant has no property database, no MLS access, no special API. It used web search, basic arithmetic, and structured reasoning to compress 30 minutes of manual research into a 60-second read. The same approach works for evaluating a used car listing, a freelancer's portfolio, or a conference you're considering attending.

The common thread is due diligence – the boring, essential research that most people skip because it takes too long.

What connects all five

None of these are features. No product manager specced a subtitle tool. No designer mocked up a trip planner. No one wrote a PRD for "apartment due diligence." They emerged because a general-purpose agent with access to the right tools can decompose any problem into search, reason, and act.

The pattern across all five is the same: I had a real problem, I described it in plain language, the assistant figured out what tools to chain, executed, and came back with a usable result.

Chatbots give you information. Agents do work. That's the shift.

I should be honest about the limits. It doesn't always get it right. The trip planner once recommended a restaurant that had closed months earlier – great reviews online, just no longer open. I've learned to trust but verify, especially when stakes are high.

But the ratio of useful to imperfect is high enough that I now default to asking the assistant first, for almost everything. Even when it's imperfect, it compresses an hour of tedious work into five minutes of reviewing a result. And five minutes of review is always faster than an hour of doing it yourself.

That's why we built Amplify – so anyone can set up a personal AI assistant and discover their own unexpected use cases. The five I listed here are just mine. If you build something unexpected with it, I'd genuinely like to hear about it.

**
Yevhen Fychak is CTO & co-founder of Amplify. He writes about building AI agents and the things they do that he didn't expect.