If I wasn’t at Anthropic, I would be making agents using the Claude Code SDK.
But doing > talking. So I’m building in public and open sourcing a local email agent.
This is part one on agentic search.
First, why the Claude Code SDK?
Whenever I’ve built an agent in the past I ended up hand rolling the same patterns that are now just way easier to use the Claude Code SDK.
In this example I’m using it for subagents, context management, the file system & code generation.
Building Context
Email has a ton of context on me. My ideal agent should be able to (with permission):
- Know info about me like my address, phone number, etc
- Write intros based on the context I have with contacts
- Find all relevant emails to draft a response
Previous generation LLMs would use RAG to find relevant emails to put into context.
RAG is fast, but noisy and hard to maintain. In this case, I would have to index my entire inbox and keep it up to date with each email.
imo this is why a lot of lastgen AI email didn't work
With the Claude Code SDK you can use Agentic Search.
Instead of passing it in a fixed context, you let it search your inbox like a human would (e.g. by email addresses and text) to find and build its context
I have a search subagent that can search my inbox, but here’s the twist-
Instead of the tool call returning an array of emails, it writes it to a log file and then it uses grep to search across these files.
This performed way better and is super easy with the SDK.
What does this mean? I can get my agent to build a profile for me from scratch just by agentically searching my inbox.
This is what that looks like right now, it honestly surprised me by how much it was able to find.
Open source repo coming soon!
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Yesterday we tightened our safeguards against spoofing the Claude Code harness after accounts were banned for triggering abuse filters from third-party harnesses using Claude subscriptions.
Third-party harnesses using Claude subscriptions create problems for users and are prohibited by our Terms of Service.
They generate unusual traffic patterns without any of the usual telemetry that the Claude Code harness provides, making it really hard for us to help debug when they have questions about rate limit usage or account bans and they don’t have any other avenue for this support.
This is why the supported way to use Claude in your own tools is via the API. We genuinely want people building on Claude, including other coding agents and harnesses, and we know developers have broad preferences for different tool ergonomics.
If you're a maintainer of a third-party tool and want to chat about integration paths, my DMs are open.
We built a Deep Research demo for the Claude Agent SDK!
It's one our most requested use cases: spawn multiple AI agents to research a topic in parallel, then synthesize their findings into a report.
🧵 on how it works:
At a high level:
- the main agent breaks your request into 2-4 subtopics
- it spawns researcher subagents in parallel to search the web
- each researcher saves findings to files/research_notes
- the main agent then spawns report-writer to create final report in files/reports
Using files is a great way of handling subagent communication.
Research subagents can save their findings to files and then the main agent can search across them to make sure the relevant information has been found.
Last week we shared about how you can use code generation to compose tools.
But code generation can also give your agents new capabilities- like proactively acting on your behalf.
In this case, I want to make an email agent that processes my emails.
Running an agent on every email I receive would be slow & unpredictable, so instead I'm allowing the user to generate callbacks that are called when I get an email.
Here's an example generated function:
When doing code generation, I like to think in terms of files that execute, instead of evaluating code in a repl. Files allow Claude to verify its work, create helper scripts, etc.
In my email agent, listeners are scripts in a folder that store logs as well.