Auto-meeting join by AI PM
Team member profile building by AI PM
AI meeting summary
Conversation with AI PM - auto checkin

Pathayo

I watched my founder lose three hours last Tuesday.

He was on a call with our backend engineer, then on a call with me, then back to ChatGPT trying to make sense of both, then back to us with questions he'd already asked.

By the end of it, nothing had moved.

The product was exactly where it was that morning. He just understood it slightly better and was more tired.

That's when it clicked for me.

This isn't a bug in how he works. This is the actual job he's doing every day, unpaid, untrained, and with no real fix for it.

Inspiration

I work at a small AI startup in the US. Three engineers. One non-technical founder. No PM. We can't afford one.

Our founder is smart. He has the vision, the market sense, and the conviction. He can sell the product to anyone.

What he can't do is read a PR, tell a real estimate from a padded one, or remember what we decided about the auth system three weeks ago.

So he does what many non-technical founders do in 2026. He uses AI as a translator.

He pastes what we say into ChatGPT, reads the reply, and pastes it back to us. Sometimes it helps. Often it doesn't. The context gets lost. The thread breaks. He can't be online at 2 AM when we're debugging. We can't always explain things in a way that lands.

And here's the part that bothers me.

None of this is his fault. None of it is our fault.

The system is just broken.

Two people speaking different languages, no shared memory, and no one in the middle whose only job is to close the loop.

We started looking around and realized this is everywhere.

Thousands of non-technical founders are stuck in the same gap. AI tools let them build a demo in a weekend, so they start. Then they hit the real work, the part that needs engineers, and they're stranded.

They either build alone with AI and ship something that breaks in production, or they hire engineers and can't tell if the work is real.

Hiring a PM to bridge that gap can cost more than an engineer. For a three-person startup, that can be the difference between a year of runway and six months.

As AI makes it easier to start companies, more non-technical founders will enter this gap.

The problem isn't shrinking. It's growing.

That's what made us build Pathayo.

Not a market opportunity.

A pain we were watching happen every day.

What it does

Pathayo is an AI project manager.

The founder talks to it in plain English, the way they'd talk to a person, and it runs the engineering management loop from there.

It learns the product

The founder explains what they're building in simple terms.

Pathayo asks the right follow-up questions and stores everything in a per-organization knowledge graph.

It remembers decisions, people, conversations, commitments, and context.

The thing that was breaking our founder — lost context and forgotten threads — was the first thing we wanted to fix.

It interviews engineers

Pathayo interviews engineers through Slack automatically.

These aren't forms. They're real conversations.

It learns who's good at what, who ships on time, who needs nudging, and what each engineer is currently working on.

The result is a living profile of every person on the team that evolves as they work.

It plans and assigns work

Pathayo breaks product goals into actionable work, matches tasks to engineers based on skills and availability, and creates Jira tickets.

The founder doesn't need to manage a project board.

It joins meetings

Pathayo can join meetings through Recall.ai, transcribe conversations, and extract decisions, action items, owners, deadlines, and risks.

Low-confidence decisions go into an approval queue, so the founder stays in control of the calls that matter while Pathayo handles the routine work.

It checks in every day

Pathayo communicates with engineers through Slack.

It asks about status, blockers, and follow-ups.

It speaks to engineers in their language — commits, PRs, CI, blockers — and explains the same information to the founder in plain English.

It tracks execution

Pathayo connects engineering activity to assigned work.

Commits, pull requests, messages, deadlines, and other signals are matched against tasks.

Every task receives an execution score from 0–100 based on real activity, deadlines, and confidence.

If something stalls, escalation rules can fire automatically:

Slack nudge → manager → founder

The founder finds out before a small blocker becomes a major problem.

It reports back

Every week, Pathayo gives the founder a report in human terms:

What shipped
What slipped
What's blocked
What needs attention
What can be ignored

The goal isn't more project-management software.

The goal is for the founder to finally know what's actually happening.

How we built it

The stack is Python, FastAPI, and a knowledge-graph memory service built on FalkorDB with vector search.

Each organization gets its own isolated graph, so one company's memory never bleeds into another's.

The memory pipeline

Memory was the core of the system.

Every conversation that flows into Pathayo — whether from the founder chat, Slack, or meeting transcripts — is processed by an LLM that extracts atomic facts.

Each fact contains structured information such as:

Subject
Predicate
Value
Topics
Entities
Sentiment
Due dates

Each fact is embedded and deduplicated against existing knowledge.

When a newer fact contradicts an older one, the old fact can be superseded rather than simply accumulating forever.

That matters because people change their minds. Estimates slip. Decisions get reversed.

A useful memory system has to update, not just accumulate.

Hybrid retrieval

When the PM agent needs context, Pathayo combines multiple retrieval strategies:

Intent understanding
Vector search
Graph traversal
Recency weighting
Optional reranking

The goal is simple:

When Pathayo responds, it should feel like someone who was in the room last week — not a fresh chat window.

Integrations

We wired the system into the tools an engineering team already uses:

Recall.ai for meeting bots and transcripts
GitHub webhooks for commits and pull requests
Slack for check-ins and engineer interviews
Jira for task creation
Google Calendar for scheduling and context

The Django backend handles OAuth flows and relays conversations to the memory service.

SAQ and Redis handle asynchronous jobs so ingestion and processing don't block the API.

For AI workloads, we use multiple models for different jobs.

Gemini API handles long meeting transcripts and extracts decisions, action items, owners, and deadlines.

Cerebras with gpt-oss-120b handles many of the high-frequency reasoning workloads, including memory extraction, founder conversations, Slack check-ins, engineer interviews, execution scoring, and reports.

The split lets us use the right model for the right workload while keeping latency and costs manageable.

Challenges we ran into

Memory was the hardest part

A PM is useless if they forget what was said last Tuesday.

Building a system that extracts facts, deduplicates them, supersedes outdated information, and retrieves the right context — without hallucinating or pulling in irrelevant history — became most of our work.

We went through several iterations on deduplication thresholds and retrieval weights before the system started feeling reliable.

Trust calibration

Early on, Pathayo would confidently turn a passing comment into a task or assign something to the wrong person.

That was unacceptable.

We added confidence scoring, evidence-based reasoning, and an approval queue so uncertain decisions don't silently become real work.

The result is a system that can be autonomous where it's safe while keeping a human in control where it matters.

Making Slack interviews feel human

Engineers don't respond well to a bot that feels like a form.

We had to make the interviews conversational, follow up on vague answers, avoid repetitive questions, and know when to stop.

That required a lot of prompt iteration and reviewing real conversation transcripts to identify where the experience felt robotic.

Scope

Honestly, this was one of our hardest challenges.

There are hundreds of things a PM can do.

We had to decide which ones actually matter for a three-person startup and leave everything else for later.

We focused on the core loop:

Meeting capture → Memory → Task assignment → Check-ins → Execution tracking → Founder reports

Everything else can wait.

Accomplishments that we're proud of

We're proud that we didn't just build a chatbot or a collection of disconnected AI demos.

We built an end-to-end management loop.

A decision made in a meeting can become a task.

That task can be assigned to an engineer.

Pathayo can check in with that engineer through Slack.

GitHub activity can update the execution state.

If the work stalls, Pathayo can escalate it.

And the founder can ask what is happening and receive an answer based on the actual history of the project.

We're particularly proud of:

Building persistent AI memory using a knowledge graph.
Giving each organization isolated project memory.
Integrating Slack, GitHub, Jira, Google Calendar, and Recall.ai.
Using Gemini API for real meeting understanding.
Building automated task extraction and assignment.
Creating AI-driven Slack check-ins and escalation.
Tracking execution using real engineering activity.
Building confidence thresholds and human approval into the autonomous workflow.
Creating a founder-facing interface that explains technical progress in plain English.

Most importantly, we built something we would actually want to use ourselves.

What we learned

The biggest lesson was about memory, and it wasn't technical at first.

We realized our founder's real problem wasn't that he didn't understand the technology.

It was that he couldn't hold the context.

Six weeks of decisions were scattered across Slack, calls, DMs, and conversations. By the time something came up again, the original conversation was buried and forgotten.

The breakdown wasn't in intelligence.

It was in continuity.

That reframed the entire project for us.

We stopped thinking about Pathayo as a chatbot that answers questions and started thinking about it as a system that never forgets.

The knowledge graph became the heart of Pathayo, not a feature.

Every decision, every commitment, every person's track record is stored and retrievable in context.

That's what a real PM does.

They remember.

The second lesson was about trust.

AI extraction is wrong sometimes. If you let it run unchecked, it can create more chaos than it solves.

We learned that the goal isn't maximum autonomy.

It's useful autonomy.

Pathayo should handle the 90% of repetitive, low-risk management work automatically while keeping humans in control of the decisions that actually matter.

That balance took us a while to get right.

What's next for Pathayo

We're not trying to replace engineers.

We believe real engineers are the only way to build something real.

The reason many non-technical founders struggle to work with engineers isn't that they don't want to hire them.

It's that they can't manage them, can't verify the work, and can't afford a PM to bridge the gap.

Pathayo is our attempt to close that gap.

A non-technical founder with an idea and the courage to start should be able to build a real product with real people — without becoming a full-time manager, without losing sleep over whether the work is real, and without burning runway on silence.

Our next priorities are:

1. Make the founder experience better

The founder should feel like they're talking to a PM who genuinely knows their company, not an AI chatbot.

2. Improve decision reliability

We'll continue improving confidence estimation, evidence gathering, approval workflows, and verification before actions are taken.

3. Understand engineering progress better

We want Pathayo to become better at understanding GitHub activity, PRs, CI failures, blockers, and actual progress instead of relying primarily on self-reported status.