DEV Community

Teruo Kunihiro
Teruo Kunihiro

Posted on

Building a Home Personal Assistant with Claude Managed Agents

#claude #ai #agents #automation

Introduction

Claude Managed Agents was just announced, so I tried using it to build a personal assistant for household tasks.

What I wanted was pretty simple: an AI I can call from Slack that can handle family notes, tasks, reminders, and schedules without too much ceremony. Things like birthdays, what gifts I bought last year, school handouts, grocery co-op deadlines, and small day-to-day household tasks.

My first impression was very positive. Claude Managed Agents solves a lot of the annoying parts up front:

  • I do not have to host the execution environment myself
  • Vaults and sandboxes are built in from the start
  • MCP and custom tools make it easier to build a safer architecture

That said, it does not eliminate the need for surrounding application code. I still needed a Slack event endpoint, persistent task state, and scheduled execution. In the end, I landed on an architecture centered on Claude Managed Agents, with Lambda + DynamoDB + EventBridge Scheduler around it.

My app is like this.

What I wanted to build

These were the rough requirements:

  1. Trigger the AI from Slack mentions for household tasks
  2. Let the AI take notes and transcribe things
  3. Connect with Google Calendar and Drive so important things are not missed
  4. Have the AI send a daily reminder about household tasks
  5. Let me send rough notes about finished tasks or recurring events and have the AI remember them in a useful way

So far, the parts that are actually working are mainly 1 / 2 / 4 / 5. Calendar and Drive integration are next.

Quickstart was genuinely useful

I started from the Claude Console Quickstart:

It is a good way to get an initial agent configuration in place. You can shape the setup through conversation instead of writing everything from scratch. Japanese IME input still felt a little awkward, and Enter could fire too early, but overall it was fast enough to be useful.

Slack MCP

On the Slack side, I created a bot account and added the scopes I needed. The main ones ended up being:

  • app_mentions:read
  • chat:write
  • files:read

The Slack MCP lives on the Managed Agent side, but actual event ingestion and attachment retrieval are handled by Lambda. In practice, that split felt better than trying to force everything through MCP alone.

Sandbox

Claude Managed Agents also gives you a managed execution environment. In this project I used a sandbox configured for Slack MCP calls and custom tool usage.

I did not let the agent touch DynamoDB directly. Instead, DynamoDB access goes through custom tools, and Lambda performs the actual reads and writes. That keeps the permission boundary clear and makes the update rules easier to control from the application side.

In Anthropic's docs, this execution environment is modeled as an Environment. An Environment is basically the container configuration where the agent runs. You create it once and refer to it by ID. Multiple sessions can reuse the same Environment definition, but each session gets its own isolated container instance, and filesystem state is not shared across sessions. In other words, configuration is reusable, but runtime state is isolated per session.

References:

That matters a lot. Even for a personal or family assistant, it means each run starts from a clean, isolated environment instead of inheriting leftovers from the previous run. Network settings are also part of the Environment, and Anthropic recommends using limited networking with explicit allowed_hosts for production. So the sandbox is not just “a safe box for Claude.” It is the unit that bundles isolation, dependency setup, and network permissions together.

Vault

I stored the Slack MCP credentials in a Vault. Not having to place raw credentials directly into the agent configuration is a big win.

The value of Vaults is pretty clear in Anthropic's docs. Vaults and credentials are treated as reusable authentication primitives that you register once and reference by ID. That means you do not need to run your own secret store for this part, pass tokens around on every request, or lose track of which credentials a session is using.

Reference:

Another important point is that MCP server definitions and authentication are separated. When you create the agent, you declare which MCP servers it can connect to. When you create a session, you pass vault_ids to resolve authentication. Anthropic explicitly calls out that this separation keeps secrets out of reusable agent definitions while still letting each session authenticate with different credentials if needed. For a setup like this, where Slack MCP exists alongside application-managed Slack event handling, that split is very helpful.

Reference:

I still needed regular application code

At first I thought Managed Agents might cover most of it. In practice, I still needed surrounding application code for three reasons:

  • an HTTP endpoint for Slack Events API
  • asynchronous processing to stay within Slack’s 3-second response limit
  • application state such as memory, tasks, sessions, and idempotency

So the architecture ended up looking like this:

Slack mention
  -> API Gateway
  -> Lambda (ingress)
  -> SQS
  -> Lambda (worker)
  -> Claude Managed Agent
  -> Slack reply

Daily reminder
  -> EventBridge Scheduler
  -> Lambda (scheduled runner)
  -> Claude Managed Agent
  -> Slack post

State
  -> DynamoDB
Enter fullscreen mode Exit fullscreen mode

Slack mentions flow through ingress Lambda -> SQS -> worker Lambda. Slack gets an immediate ACK, and the Claude interaction happens asynchronously in the background.

The daily reminder is triggered by EventBridge Scheduler. Right now it runs every day at 09:00 JST and posts a reminder for unfinished tasks.

What gets stored where

This setup currently uses seven DynamoDB tables:

  • SlackThreadSessionsTable: mapping between Slack threads and Claude sessions
  • ProcessedEventsTable: Slack event deduplication
  • ScheduledTasksTable: scheduled task definitions
  • UserMemoriesTable: mapping to Claude memory stores
  • MemoryItemsTable: semi-structured memory persisted through custom tools
  • TasksTable: current task state
  • TaskEventsTable: task history

MemoryItemsTable and TasksTable / TaskEventsTable are the important ones here.

For household use, the data I actually care about looks like this:

  • whose birthday it is
  • what I gave them last year
  • what tasks are still unfinished
  • whether a task is already done

That kind of information is easier to manage if it lives in DynamoDB as the source of truth, with Claude pulling it through tools only when needed. That is the approach I took.

Using custom tools for memory and tasks

I ended up defining these five tools:

  • search_memories
  • save_memory
  • list_tasks
  • upsert_task
  • mark_task_done

When the Managed Agent calls one of them, it emits agent.custom_tool_use. Lambda receives that request, updates DynamoDB, and returns the result via user.custom_tool_result.

I like this pattern a lot. The agent never needs direct DynamoDB IAM permissions, which makes the boundary safer and gives the application control over how updates are applied.

I verified the flow end to end:

  • save_memory stored “Hanako’s birthday is 8/12”
  • upsert_task created a task for buying a birthday gift
  • mark_task_done updated that task to done
  • TaskEventsTable recorded created and marked_done

Slack mentions work naturally

When I mention @AI in Slack, the conversation continues in the same thread.

What made this feel right was treating Slack thread = Claude session. That aligns the Slack UX with the conversation context in a very natural way.

I also added attachment handling on the Lambda side. With files:read, Lambda can fetch PDFs or images from Slack’s url_private endpoints and pass them to Claude as document or image blocks.

That makes flows like this possible:

  • upload a school or daycare PDF
  • let the AI read it
  • extract tasks if needed
  • save important details into memory

Daily reminders also worked well

For scheduled execution, I used EventBridge Scheduler rather than the older CloudWatch Events style rules.

The current setup stores a daily-summary task definition in DynamoDB. Every morning at 9 AM, the scheduled runner loads that definition, starts Claude, calls list_tasks to fetch unfinished tasks, and posts a short reminder to Slack.

What I like about this is that the reminder is not a fixed template. Claude can shape the wording based on the unfinished tasks in DynamoDB.

Letting it read PDFs and remember things is surprisingly good

This turned out to be one of the most promising parts for household use.

If I can just upload a PDF to Slack and say @AI take a look at this, the system can:

  • extract dates
  • turn them into tasks
  • save names or events into memory

That is exactly the kind of workflow that matters for family operations, where the problem is usually not a lack of information but forgetting things at the wrong time.

In that sense, save_memory and search_memories seem especially useful.

Pricing

Cost is obviously a concern.

According to Anthropic’s pricing page, the model I am using here, Claude Sonnet 4.6, is priced at:

  • Input: $3 / MTok
  • Output: $15 / MTok
  • Session runtime: $0.08 / session-hour

Reference:

For household use, a rough estimate still puts this in a pretty reasonable range, around $10/month.

I used these assumptions:

  • 5 Slack mentions per day
  • 1 daily reminder per day
  • per mention: 12k input tokens / 1.2k output tokens / 20 seconds runtime
  • per reminder: 15k input tokens / 1.5k output tokens / 15 seconds runtime

That gives roughly:

  • mentions: about $8.4 / month
  • reminders: about $2.1 / month
  • total: about $10.5 / month

This will go up quickly if:

  • you read a lot of long PDFs
  • you use web search or extra tools heavily
  • conversations get long and context keeps expanding

Still, for a personal household assistant with a small number of daily interactions, AWS costs are likely minor compared to Claude token costs.

Things that were tricky

Slack Events configuration

At first, I had the classic problem where the Request URL was verified but no events were arriving. In the end, I had to carefully make sure that:

  • Event Subscriptions were enabled
  • app_mention was added
  • files:read was added
  • the Slack app was reinstalled after changing scopes

Splitting responsibility between Slack MCP and Lambda

Slack MCP is useful, but once you need external event ingestion, attachment handling, threaded replies, and idempotency, it is easier to keep Slack input/output under application control.

The split that worked best here was:

  • Lambda handles input and delivery
  • Managed Agent handles reasoning and tool usage

That division felt clean.

Do not start with fully automatic memory saving

This is more of an operational lesson than a technical one. Memory gets messy fast. Birthdays and gift history are good durable facts, but if you save every temporary request automatically, the memory store becomes noisy very quickly.

For now, I prefer having an explicit save_memory entry point. The agent can decide what looks durable, but the application still controls how it is persisted.

What I want to do next

These are the next things I want to add:

  • register events in Google Calendar and link the returned event IDs to tasks
  • read Google Drive documents and turn them into tasks or memories
  • run weekly summaries of completed tasks
  • add reminders like “a birthday is coming up” or “the co-op deadline is close”
  • refine the memory persistence policy

Calendar integration feels especially important. The shape I want is: Claude registers something in Calendar, returns structured JSON, and the application syncs that result into DynamoDB task state.

Closing thoughts

I came away with a very good impression.

The managed aspect matters a lot. Availability, execution environments, credentials, and permission boundaries are all expensive to get right on your own. Claude Managed Agents makes that much easier to control.

The pattern that currently feels best to me is:

  • reasoning and sandboxing in Managed Agents
  • webhooks, state, and integration glue in Lambda

That split worked well for a household assistant too. At this point I can already see a path where I throw rough notes into Slack and get “remember this,” “remind me later,” and “what is still unfinished?” out of the same system.

The next step is to connect Calendar and Drive and see how far this can go in real day-to-day use.

References

Top comments (0)