I built an 11-agent AI team to do my own work. Seven weeks later, I checked whether I was using it.
64 agent calls. Exactly one went to a named agent on the roster. This experiment to do real work failed.
Everything else went to a generic agent, or I just did the work myself in the main session.
Two of the eleven agents were never called. I deleted them.
Here is the part I got wrong. I thought the agent roster was the product. Build the specialists, name them, give them tools, and the work routes itself. It doesn't. Nothing in the system handled the main session handoff, so it kept the work. Keeping the work is always the shortest path in the moment.
The roster wasn't broken. The routing was. I never wrote the orchestration rule.
So I wrote it down. The main session routes and synthesizes. The agents do the work. That is now the first thing the system reads.
The general version, for anyone standing up agents right now. If your AI adoption metric is whether you built the thing, it is lying to you. Count invocations per agent. An agent nobody calls is a file, not a teammate.
Have you had a similar experience?
When's the last time your job description actually reflected your role?
I'll go first. I'm a director of engineering. On any given day, I might be mentoring a junior developer through their first architecture decision, coaching a senior engineer through a difficult conversation, reviewing pull requests, writing code, sitting in a planning meeting, and thinking about organizational design. Sometimes all before lunch.
None of that fits neatly into a job description. And I've been sitting with a question lately: why do we let job descriptions define what a role is?
A job description is a recruiting tool. It exists to attract someone to an organization. A role is the collection of responsibilities you actually carry every day. One is a marketing document. The other is your lived experience. And in engineering, the gap between those two things can be enormous.
Look at any two "Director of Engineering" postings. One company expects you to be purely strategic. Another expects you to still be deep in the code. One wants a process builder. Another wants a technical mentor. Same title. Completely different roles. And neither job description fully captures what the person in that seat actually does once they are there.
I think this is where a lot of professional frustration lives. You're doing meaningful work that matters to your team. You're wearing hats that nobody asked you to wear, but everyone depends on. And when you look at your job description, or worse, when someone else looks at it, the work you're most proud of is invisible.
The problem is not that job descriptions exist. The problem is that we treat them as role definitions when they were never designed for that. A job description is the last artifact, not the first. The role comes first. The responsibilities come first. Understanding what a team actually needs from this seat comes first.
I'm not arguing that we stop writing job descriptions. I'm arguing that we stop confusing them with the work.
I'd love to hear from others: does your job description reflect what you actually do? Or is your role something entirely different?
Ever have one of those moments where your coworkers think it would be fun to create a game? I did this week, and I created Bonq. This is a crazy blend of Kahoot and Jackbox.
What if you had a digital twin that didn't just chat — but actually did the work?
I just joined the Apex waitlist. It's a fully autonomous AI agent that handles comms, decisions, and real tasks on your behalf — 24/7.
Get early access: https://t.co/uAFv4LMyR2
If prototype-first becomes the norm:
What happens to Jira and Confluence?
What does the PM role look like when the first draft is working code, not a doc?
What surprised you if you've already tried this?
The conversation is shifting. Let's shape it together.
I'm not arguing against rigor. I'm arguing for reordering it.
Build to understand. Document what you learned. Plan the production path with the confidence that comes only from having touched the problem.
The tools and ceremonies aren't wrong. They're in the wrong order.
Claude Code, Codex, and similar tools changed the economics of exploration.
A concept that took weeks now takes hours. An engineer + agent can prototype before lunch. Not to ship. To LEARN.
When building is cheaper than specifying, why are we still specifying first?
For the last decade, PRDs became the starting line. Engineers didn't touch code until the spec was "done."
Good reasons for that. Alignment, hard conversations, shared understanding.
But what if the PRD isn't wrong... Is it just in the wrong place in the workflow?
My dad never wrote down his philosophy on work.
But I watched him show up early for thirty years. I learned that consistency is its own kind of sermon.
My mom never documented her theology of generosity.
But I saw her give when it didn't make sense on paper. I learned that margin exists to be shared.
Most of what shapes us was never written down. It was lived in front of us.
Work ethic. Forgiveness. How to pray when you don't have words. How to stay married when it's hard.
Here's what I think about now:
What am I living in front of my kids that I've never said out loud?
And what did my parents live that I might forget if I don't capture it soon?
Pathible isn't a document vault. It's a place to preserve what was lived, before it fades.
What's one lesson your parents taught you without ever writing it down?
I used to think that faithful families handled hard seasons better.
Less confusion. More peace. A kind of holy calm when aging and illness arrived.
Then I walked through it myself.
The chaos still came. Searching for documents at 11pm. The conversations nobody wanted to have. The weight of decisions made without enough information.
Faith didn't remove any of that.
But it gave it meaning.
It gave me something to hold onto when I didn't have answers. It reminded me that preparing for hard things isn't faithless. It's wise.
Proverbs is full of this. Prepare. Plan. Think ahead. Not because you're afraid, but because you love the people who'll come after you.
If you're in a calm season right now, that's not the time to coast.
It's time to prepare.
So that when the chaos comes, and it will, your family has clarity instead of confusion.
That's love with your eyes open.
There's a day that comes for most of us.
Your dad asks what you think he should do about his retirement account. Your mom wants you to come to the doctor's appointment. Not to drive. To listen and remember.
The questions they used to answer, they're now asking you.
It's disorienting. Sometimes it feels like a loss. Sometimes it feels sacred. I've felt both in the same conversation.
I've learned that preparation isn't about taking control from your parents. It's about honoring them.
It says, "I see that things are changing." I want to walk through this with you, not scramble after you're gone.
Starting the conversation while everyone's healthy isn't morbid. It's kind.
If you've felt that shift, where you became the adult in the room without anyone announcing it, you know what I mean.
The best time to prepare was before the shift. The second-best time is now.
Most people inherit responsibility long before they inherit money.
You start getting the calls. The questions about medications. The requests to "just look at this bill." The assumption that you'll know what to do.
Nobody hands you a manual. Nobody asks if you're ready.
I think about Proverbs and how it frames inheritance as wisdom passed down, not just assets transferred. But somewhere along the way, we started thinking inheritance meant what's in the account.
The most valuable thing you can leave your family is clarity.
Where things are. What you want. Who to call.
Small acts of preparation are small acts of love. They say: I'm not going to make you guess.
If you're carrying responsibility today that you were never prepared for, you're not alone.
And if you have the chance to prepare someone else? That's the inheritance worth leaving.
A small moment of gratitude today.
Families have started quietly using Pathible.
Uploading documents.
Thinking about wills.
Writing notes that their children may one day read.
No launch announcement.
No campaign.
Just people choosing to prepare with intention.
That is more meaningful to me than any metric.
Building this has reminded me that the best products often begin as acts of care.
If you are working on something rooted in purpose, I would love to hear about it.
The hardest part of building something personal is not the technology.
It is deciding what not to build.
Every feature is a temptation.
Every idea feels meaningful.
But when the product is meant for families in fragile moments, simplicity becomes a moral choice.
Fewer buttons.
Fewer decisions.
Less noise.
Clarity is kindness.
That principle has shaped Pathible more than any technical decision I have made.
Where in your work have you had to choose simplicity over power?
There is a strange moment that happens when your parents stop giving advice and start asking questions.
About paperwork.
About insurance.
About passwords and accounts.
It is subtle, but it changes the relationship.
You realize you are slowly becoming the steward.
Not just of finances.
Of history.
Of decisions.
Of unfinished conversations.
That transition is part of what led me to build Pathible.
Not to manage money.
But to help families take responsibility with clarity, not confusion.
Have you noticed that shift happening in your own family yet?
I had a quiet moment recently with one of my kids.
We were not talking about money.
Or college.
Or careers.
We were talking about family.
Stories about grandparents they never met.
Why certain values matter to us.
What kind of people do we hope they become?
It struck me how little of this ever gets written down.
We pass along accounts and assets.
But the things that shape identity often disappear in a single generation.
Pathible exists largely because I do not want that to happen in my own family.
What stories from your family do you wish had been preserved?
One of the unexpected parts of building this product has been realizing how much my beliefs shape design decisions.
What we store.
What we protect.
What we make simple.
What we never monetize.
Faith shows up in small places.
In choosing clarity over complexity.
In designing for families, not just users.
In believing that preparation is an act of love, not fear.
Pathible reflects that more than I realized when I started.
What personal beliefs shape the way you build and lead?