Helm
My approach to turning client and agent activity into decisions.
I designed and built Helm around one decision at a time. Explore my approach to agent activity, client context, rules, and review before sending.
- Next.js
- React
- TypeScript
- Zod
- PostgreSQL
- Background jobs
- Claude, OpenAI & Grok APIs
- GitHub API
- Gmail & Slack APIs
- Encrypted key vault
- Vercel
- GitHub Actions CI/CD
My contribution and decisions
I designed and built the product end to end. My focus is making the next decision clear when client conversations and agent runs compete for attention.
The decision deck, client board, and plain-language rules connect the work to its context. Per-client settings make access, communication preferences, and review part of the experience.
What it does
One decision at a time.
Helm reads every client thread and every agent run, then deals you only what needs a person, most urgent first. Answer one and the next is up. Try it.
- Drafts, failing checks and agent questions, one tap each
- Every running agent in the dock, whatever the model
- Starting work puts a new agent in the dock
Dive into any client.
A board of what they asked for, what’s building, what’s in review and what shipped, with Helm’s suggestions beside it in priority order.
- Suggestions that move the board when you act
- This week’s update rhythm at a glance
- Ask anything about the client
Rules you write in plain words.
Say it the way you’d say it. Helm asks only what it needs, writes the rule out and shows exactly which days it will step in. Try it.
- When, what counts, then, always
- A two-week preview before it’s on
- Nothing sends without your review
The right person, in their voice.
@ anyone at a client and Helm knows how they like to hear from you: the channel, the tone, what they get. Try it.
- @ mentions for everyone at every client
- Channel and tone per person
- Learns from what you’ve already sent
Everything about a client, in one place.
People, channels and quiet hours, voice, scoped access keys, rules and docs, set once and used by every agent that works for them.
- Keys scoped per client, rotated in place
- Quiet hours in the client’s time zone
- Briefs and contracts the agents can read
Add a client in six questions.
Who they are, how they talk, who you write to, how you sound, what Helm can touch and any rules, one card at a time.
- Channels, with one marked primary
- People added by @handle
- Access connected as you go
Why it’s built this way.
Why one decision at a time instead of a dashboard?
Because a dashboard leaves the sorting to you. Helm ranks what needs a person (an update you promised, an agent waiting on an answer, a failing check) and shows one at a time, so you clear the morning instead of scanning it.
How does it decide what comes first?
Promised update rhythms that are due, agents blocked on a question, failing checks, how long a client has gone without hearing from you, and how big the engagement is.
Which AI agents does it work with?
Claude, OpenAI and Grok in the cloud, and agents running on your own machine. Every run shows its model, and you can hand a session to a different model without losing the conversation or the sandbox.
Does it ever message a client on its own?
Only if a rule you wrote says so. By default Helm drafts and you send, and either way it respects each client’s quiet hours.
Where do client keys live?
Scoped per client, encrypted at rest and never shown in full. Each key says what it can touch and when it was last used, and rotates in place.
Who built it?
Nicholas Howell, designed and built end to end. It’s how I’d build your product, too.