We're entering an era where software adapts to you, not the other way around.
For decades, we've built tools that solve problems for millions of users the same way. You learn the interface, memorize the shortcuts, adapt your thinking to match the software's logic. LLMs enable a different approach: software that molds itself to how you specifically work. At Civic, we discovered this almost by accident while fixing MCP servers that were drowning Claude in 18,000 tokens of tool descriptions. What we built was a framework where software starts to understand your patterns.
Right now, you still have to tell it what to do. But the foundation is there for more. It could remember your last 10 tool calls and optimize behind the scenes. Or walk you through a wizard that adapts based on how you've worked before. We've built filters that hide irrelevant tools, parameters that prepopulate with your defaults, aliases that match your vocabulary, post-processors that cut token usage by 70%. Each piece makes the software a little more yours.
The shift is subtle but real. When I work with GitHub now, I don't see 47 generic tools. I see 5 that match how I actually work. When I say "query," it knows I mean the database, not the search. The system is learning my language, not forcing me to learn its language. This has the potential to fundamentally change how we interact with software, from commanding tools to collaborating with them.
The Before and After
Here's what changed. Before: I tell Claude to "send the meeting notes to the team." Claude sees 150+ tools across all my connected services. Gmail's 30 tools, Slack's 25, Google Drive's 20, Notion's 15, GitHub's 47, and more. It starts with `gmail_create_draft`, then tries `slack_search_users` to find "the team," then `gdrive_create_document` thinking I want to create notes, then `notion_search_pages` looking for existing notes. Each attempt burns context. Each service loaded thousands of tokens of tool descriptions. Claude is drowning in possibilities when I just wanted to send an email.
After: I say "send the meeting notes to the team." Claude sees 5 tools total. It knows "the team" means my engineering@ email list. It knows meeting notes live in our Notion space. It knows I always send from Gmail, not Slack. The system has learned that when I say "send," I mean email. When I say "team," I mean that specific list. When I reference "notes," they're in Notion. First try, right action. The software has adapted to my vocabulary, my workflows, my defaults.
Other companies achieve the same goal with routers and progressive disclosure. We chose to handle this issue through a different technical approach that unlocks more useful context, where routers and progressive disclosures limit it.
The Technical Breakthrough
The breakthrough wasn't a single innovation. It was recognizing that LLMs process information like we do. Limited working memory. Better with fewer, clearer choices. Needing context, not catalogs.
So we built simple mechanisms that compound into personalization. Think of them like preferences that shape how the software presents itself to you.
First, we filter. Instead of showing all 150+ tools, we show only what's relevant to your current task. Writing code? See GitHub tools. Scheduling meetings? See calendar tools. The rest stay hidden.
Second, we prepopulate. The system remembers your defaults: your repository, your email lists, your folders. You don't specify them anymore. They're just there.
Third, we translate. That tool called `execute_log_insights_query`? You just see "query." The system speaks your language, not engineer-speak.
Each mechanism is simple. Together, they create software that knows you. Not through some complex AI learning algorithm, but through deliberate design that respects how both you and the LLM actually work. We're not making the LLM smarter. We're making it more focused, more personal, more yours.
How It Actually Works
Let me show you how this works in practice. Last week, I set up a profile for my AI development and speaking engagements. Here's what changed.
Before, I'd have to say: "Create an issue in github-remote, assign to tyronemichael, label as enhancement and mcp-server, about the OAuth flow bug."
Now I just say: "File OAuth flow bug."
The system knows my patterns. Issues get assigned to me. MCP work gets specific labels. My default repo is civic-mcp2. All of this got configured into my profile in minutes, not through AI training, but through deliberate setup that captures how I actually work.
Same with my calendar. Before: "Create a calendar event for ProductCamp Austin, add Google Meet, set reminders for 1 day and 1 hour before." Now: "Add ProductCamp Austin to calendar." The system knows I always want Meet links for speaking events. It knows my reminder preferences. It just works.
Behind the scenes, the framework filtered out 40% of tools I never use. Eight Gmail tools for filters and batch operations I don't need. Dozens of GitHub tools for advanced operations. It created intuitive aliases like `file_bug` and `find_mcp_examples`. It cloned commands for different contexts. `create_mcp_docs` for technical guides. `create_speaking_notes` for presentations.
Watch someone set this up for the first time. They describe their workflow once. The system adapts. Suddenly, software that used to require paragraphs of instructions understands simple phrases. The software finally gets how they think.
The Client Value
This same framework lets us rapidly adapt software to how our clients work. Not how we think they should work. How they actually work.
When a client says "pull our inventory," we can make the system understand they mean their specific QuickBooks report, formatted their way, sent to their team. We don't force them to learn our language. We adapt to theirs. We observe their patterns, document their workflows, and build software that feels intuitive to them because it literally speaks their language.
This is how enterprise software becomes intuitive. Not through fancy AI, but through careful attention to how people actually work. A law firm doesn't "search documents." They "pull precedents." A construction company doesn't "create tasks." They "schedule crews." The framework lets us capture these nuances and make the LLM understand them too.
We can ship software that feels like it was built specifically for each client. Because in a way, it is. Their terminology. Their workflows. Their defaults. The LLM isn't confused by their industry jargon or unique processes. It's been adapted to think like they think.
This shifts how we deliver solutions. Instead of months of training and change management, clients get software that works like they already work.
What This Enables
This is just the beginning. Right now, you still tell the software what to do, but it understands you better each time. The foundation we've built at Civic opens doors to something more interesting.
Imagine software that notices you always run three specific commands in sequence and suggests combining them. Or an LLM that remembers your last week of work and automatically adjusts its tools for your current project phase. Or wizards that adapt their questions based on how you've answered before. Never asking for your repository again because it already knows.
We're moving from software that treats everyone the same to software that develops a relationship with you. Not in some creepy surveillance way, but like a colleague who learns how you work and adjusts accordingly.
The technical wins matter. 70% less token usage, better accuracy, faster responses. But what interests me is the philosophical shift. We've spent decades learning to think like our software. Now we're building software that learns to think like us.
At Civic, we built this to solve a context problem. What we discovered was a new way to relate to our tools. Software doesn't have to be universal anymore. It can be personal. It can be yours.
The framework is real. The results are measurable. And I think we're just scratching the surface of what personal software can become.
