🧭
Designing My Own Agentic Interface
A personal agentic system that actually knew me. Not a chatbot. Not another productivity app. A framework I owned, running on my own hardware, that could get smarter about my goals over time.
| Dimension |
Details |
| Role |
Designer & Builder |
| Tools |
Claude, Claude Code, SwiftUI, OpenCLAW |
| Timeline |
2 weeks (nights & weekends) |
| Status |
Shipped & In Active Use |
When OpenCLAW launched in early 2026, I saw it as the missing piece for something I'd been wanting to build: a personal agentic system that actually knew me. Not a chatbot. Not another productivity app. A framework I owned, running on my own hardware, that could get smarter about my goals over time. I built the framework in two weeks alongside my full-time role at BNY. Then I built a native iOS app to live inside it — because the interface I was using wasn't good enough for what the system had become.
🧩
Nothing Knew Me
I wasn't drowning in tools. I was drowning in context-switching between them.
Design questions in one Claude project. Work strategy in another. Writing drafts scattered across Notion and half-finished conversations. A firehose of AI and design content with no way to filter what actually mattered to my trajectory. Every conversation started from zero. I repeated context constantly. Nothing compounded.
The deeper frustration was control. I wanted a system that lived on my own devices, updated over time, and gave me a coherent picture of what mattered — without syncing my thinking to someone else's servers.
OpenCLAW gave me the architecture to build that.
⚙️
Four Agents, One System
Before writing any code, I sat down with Claude and designed the agent structure. The core decision was to separate concerns from the start — four specialized agents rather than one assistant trying to do everything.
Penn — Router
Routes everything. Every message gets triaged by Penn, which determines which agent should handle it and routes accordingly. Lightweight by design — Penn doesn't do much besides connect the system.
BNY Strategist — Work Context
Owns my work context. Builds and maintains identity cards for the people I work with — updated each time I mention someone or drop in a meeting note. Keeps a running picture of key relationships and projects that I'd otherwise be rebuilding from memory.
Design Thinker — Writing Partner
Holds drafts, ideas, and thinking patterns. Connected to the Design Thinker Substack workflow — I can read an article through the Learning Assistant, spark an idea, and route directly to Design Thinker to develop it.
Learning Assistant — Firehose Filter
Pulls from 30+ RSS feeds across AI, design, and startups. Reads everything, surfaces what's relevant to my specific trajectory, and generates digests with TL;DRs. The content finds me, filtered to what matters.
The whole system runs on my Windows PC via a gateway and REST API, with Tailscale for secure remote access from anywhere.
📱
Why a Native App: Chat Isn't Enough
Telegram worked — eventually. Getting Penn to reliably route messages to the right agent took iteration, but it got there. The problem wasn't that Telegram broke. It was that chat is the wrong interface for living inside a system.
Everything landed in a single thread. When cron jobs fired — weekly digests, Monday briefs, content pipeline outputs — the results scrolled past and disappeared. I couldn't see my work context alongside my learning queue alongside Penn's weekly synthesis without prompting each one separately. There was no spatial view. No push notifications when something time-sensitive surfaced.
I needed something I carried with me that felt less like a conversation and more like a dashboard — one that surfaced what mattered without me having to ask.
So I built Navori.
✨
Key Decisions
The priority was connection, not visual polish.
The hardest part of this project wasn't the UI — it was getting the iOS app to reliably communicate with the OpenCLAW gateway running on my PC. The connection follows a specific handshake protocol: connect → challenge/nonce → hello-ok → then chat with the appropriate agentId. Getting that handshake right, and building fallback logic that tries local WiFi first then drops to Tailscale, was the real design and engineering challenge. Everything visual came second.
Four tabs reflecting four agent domains.
Today, Work, Write, Learn. Each tab surfaces the output of its corresponding agent in a structured view rather than a chat thread — projects and relationships from BNY Strategist, draft ideas from Design Thinker, curated articles from Learning Assistant, and Penn's daily synthesis at the top of Today.
Push notifications for cron job outputs.
The Monday Brief and weekly Learning Digest were the primary reason I needed to move beyond Telegram. Scheduled outputs that arrive while I'm working needed to interrupt me — not disappear into a scroll. Notifications made the system feel alive rather than passive.
The weekly check-in as a deliberate ritual.
Every Friday, a card surfaces a short reflection prompt. It's a small interaction with a real behavioral intent: feeding structured reflection back into the agents so the system compounds rather than stays static.
Connection transparency.
A small indicator shows whether the app is talking to the gateway over local WiFi or Tailscale. A minor detail, but it mattered for my own trust in the system — I always knew its state.
🪞
Reflection
The most important decision in this project wasn't a UI choice. It was the architecture decision to separate agent concerns from the start. Each agent owning its own memory and domain meant the system could grow without becoming a monolith. Penn staying lightweight as a router rather than a heavy orchestrator meant it stayed fast. These are product decisions as much as technical ones — and getting them right at the beginning is what made the app genuinely useful rather than just technically interesting.
"Agentic interfaces require a fundamentally different design vocabulary than conversational ones. Chat assumes you'll ask. Agents can surface."
The design job shifts from "how do I make this interaction clear?" to "what does the user need to see before they even know to ask?" That's a different problem — and one that's going to matter increasingly as AI moves from assistants to systems that act on your behalf.
I'm still building. The work agent has real limitations without integration into my work machine. Several features — piping cron job outputs directly into the app feed, in-app insight tracking after the weekly digest — are on the roadmap. But the system is useful today, which is the only bar that matters.
That instinct — ship something real, learn from using it, keep building — is what I want to bring into my next role.