About the Project
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 Autogent.
Not a market opportunity.
A pain we were watching happen every day.
What it does
Autogent 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.
Autogent asks the right follow-up questions and stores everything in a per-workspace memory built on PostgreSQL with vector search.
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
Autogent 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
Autogent breaks product goals into actionable work, matches tasks to engineers based on skills, availability, and reliability, and sends assignments through Slack.
The founder doesn't need to manage a project board.
It joins meetings
Autogent can join meetings through Recall.ai, transcribe conversations, and extract decisions, action items, owners, deadlines, and blockers.
Low-confidence decisions go into an approval queue, so the founder stays in control of the calls that matter while Autogent handles the routine work.
It checks in every day
Autogent 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 respects cooldowns so it never spams. It tracks every check-in so it never repeats the same question.
It tracks execution
Autogent 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 to 100 based on real activity, deadlines, and confidence.
If something stalls, escalation rules can fire automatically:
Slack nudge, then manager, then founder.
The founder finds out before a small blocker becomes a major problem.
It watches for risks autonomously
Autogent runs a monitor cycle every 30 minutes that scans for overdue commitments, silent engineers, single points of failure, and stale blockers.
It generates alerts with severity levels and escalates the ones that stay unacknowledged.
The founder doesn't have to ask what's wrong. Autogent tells them before they have to.
It plans sprints and tracks scope
Autogent creates sprints, plans what goes in them based on team capacity, runs retrospectives when they end, and tracks milestones against deadlines.
It detects scope creep by comparing what was originally agreed to what keeps getting added.
It tracks estimation accuracy per engineer so the founder knows whose timelines to trust.
It senses morale
Autogent reads sentiment across conversations and flags when the team is frustrated, burning out, or going quiet.
It tells the founder when someone needs attention before that person quits.
It reports back
Every week, Autogent gives the founder a digest in human terms:
What shipped. What slipped. What's blocked. What needs attention. What can be ignored.
It also generates stakeholder updates tailored to the audience, investors get confidence and numbers, the team gets specifics and next steps, the board gets risk and runway.
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 SQLAlchemy with async ORM. Everything lives in a single backend.
Memory is PostgreSQL with pgvector for embeddings. We use fastembed with the BAAI/bge-small-en-v1.5 model at 384 dimensions. Facts are stored as subject, predicate, value triples with kind, topics, sentiment, confidence, temporal status, and provenance through ingestion episodes. Repeated ingestion supersedes instead of duplicating because fact IDs are deterministic UUIDs.
Each workspace gets its own isolated memory. One company's data never bleeds into another's.
The LLM layer uses an OpenAI-compatible chat completions API with Cerebras as the default provider and OpenAI as a fallback. We wrote a resilient JSON parser that handles markdown fences, leading prose, curly quotes, trailing commas, and balanced extraction so LLM outputs don't break the system when the model misbehaves.
The agent loop is ReAct-style. It sends the conversation and tool schemas to the LLM, executes tool calls, feeds results back, and repeats until the LLM produces a final answer or the step budget is exhausted. Every step is recorded so the trace is observable.
The context engine does multi-signal retrieval. It extracts intent from the query, embeds it for vector search, traverses topics and entities, ranks by dense score combining similarity, recency, topic overlap, kind hints, overdue flags, source reliability, and confidence, then optionally reranks with an LLM associative ranking pass. The result is a prompt-ready context string with facts, project states, and person states.
The PM intelligence layer is 11 services working together: extraction, state inference, PM automation, context engine, planning, sprints, monitor, team, stakeholders, decision history, actions queue, meetings, and people. Each one has deterministic fallbacks so the system still works when the LLM fails.
The scheduler runs autonomously every 30 minutes. It auto-onboards new members, runs proactive check-ins, kicks off projects, infers state, runs the monitor cycle, escalates stale alerts, rescores tasks, and generates weekly reports. No human has to trigger anything.
Slack integration handles inbound DMs with signature verification, event dedup, and routing through the PM automation layer. Onboarding replies continue the onboarding conversation. General replies get ingested as facts and answered contextually. The system falls back to the generic agent loop if PM automation fails, so the user never gets silence.
We ported 17 PM prompts from our earlier research prototype, covering fact extraction, onboarding, project intake, check-ins, PM decisions, project state, person credibility, work review, next steps, founder digest, sprint planning, retrospectives, scope creep, stakeholder updates, performance feedback, morale sensing, and meeting summaries.
Challenges we faced
The hardest part was making the PM honest.
Most AI tools default to agreement. If an engineer says "I finished it," the AI says "great." But a real PM asks "where's the PR?" We had to teach Autogent to distinguish evidence-backed completion from verbal claims, and to say so plainly to the founder even when it's uncomfortable.
The second challenge was context loss across conversations. ChatGPT loses the thread between sessions. We solved this by persisting every fact, every decision, every commitment, and every state snapshot in PostgreSQL with vector search. Autogent's memory survives restarts, session breaks, and weeks of inactivity.
The third challenge was avoiding spam. A PM that messages engineers every 30 minutes is worse than no PM at all. We built cooldowns, check-in records, onboarding state tracking, and silence thresholds so Autogent only reaches out when there's a real reason.
The fourth challenge was the dependency on external services. Our first prototype used a separate knowledge-graph service. It added latency, deployment complexity, and a failure point. We moved everything into Autogent's own PostgreSQL database with pgvector, which let us drop the external service entirely without losing any capability.
What we learned
We learned that the gap between non-technical founders and engineers isn't a knowledge problem. It's a communication and memory problem. The founder doesn't need to learn to code. They need someone in the middle who speaks both languages and never forgets.
We learned that deterministic scoring matters more than LLM summaries. The LLM can write a nice paragraph about project health, but the founder trusts the number. When Autogent says "credibility score 0.3, 2 missed deadlines," that lands. When it says "the project seems to be facing some challenges," that doesn't.
We learned that fallbacks are the product. The LLM will fail. The network will fail. The Slack API will rate-limit. The system has to degrade gracefully and keep working. Every service in Autogent has a deterministic fallback path.
What's next
More integrations. Jira, Linear, Notion, Google Calendar, and Microsoft Calendar are wired into the OAuth flow but not yet functional. GitHub is connected and tracking commits and PRs. We want Autogent to pull from every tool the team already uses so the founder gets one unified view.
Better learning from outcomes. Decision history is stored. Outcome recording is built. The next step is feeding accuracy metrics back into the prompt context so Autogent gets better over time at knowing when to trust its own judgment.
More founders. The problem we watched in our own startup is everywhere. We want Autogent to be the thing that lets a non-technical founder hire three engineers and actually ship a product without hiring a PM.
Log in or sign up for Devpost to join the conversation.