Meet Emily, our autonomous coordination agent for work that gets stuck between people. One task. Two accountable humans. Zero operator follow-ups. Emily waits, wakes on replies, and closes only when the work is actually done. Built with Gemini + Google ADK for #AllThingsAgenticHackathon

A static snapshot can be correct when written—and still become stale. In our first MLA benchmark, agents either trusted a superseded decision or searched until timeout with no freshness signal. Research: research.meetless.ai/governe… Join Meetless: discord.gg/bfYNHqwHMJ

Spent today catching two bugs in our own tooling, and the interesting part was not the bugs. It was noticing my tests could have shipped right past both of them. Both were the same shape: a green signal nobody checked against reality. One was a health check that reported "workspace resolves" even when it resolved the wrong one. It returned ok either way, and never compared what came back to what it expected. The other treated HTTP 200 as success, when that 200 actually carried a "failed" receipt for one document. It marked the whole batch done and stranded that doc for good. Both fixes were tiny. Compare the id. Flip the status to retryable. The habit that actually saved me is the part people skip. After writing a test for each fix, I reverted the fix, rebuilt, and made sure the test went red. Then I put the fix back. If a test passes with the bug still in place, it was never testing the bug. Mutation testing, by hand, in about a minute. A test written after the fix is guilty until proven it can fail.

Building anything that watches for problems and pings a human? The hard part isn't catching things. It's not drowning the human in them. This week I reworked the surface in our product that says "here's what actually needs you right now" (it governs the changes our own AI coding agents push, so I eat this noise myself). The tempting design: show everything the detector flags, let the human triage. Feels safe, you hide nothing. It's a trap. A surface that's mostly noise trains people to ignore all of it, and the one alert that mattered goes with the rest. So we got aggressive about hiding, and made hiding safe with two rules: Dedup at the decision grain. One human decision, one card. Our first cut fanned a single decision into several cards because the raw signal had several facets. That was us manufacturing the exact noise we exist to kill. Only surface what needs a decision. Everything else becomes searchable inventory, not an alert. The subtle one: when someone rejected both sides of a flagged conflict, we first treated it as "resolved, nothing to show." Wrong. Nothing authoritative stands anymore, so that quiet-looking state is exactly the one that needs a human. The lesson for anyone building detection: don't surface everything that might matter. Surface only what needs a decision, deduped to the decision. And watch the quiet states: the one that looks resolved can be the one that needs you most.

AI agents need a resolver for organizational context. - A coding agent can read your repo. - An internal agent can search your docs. - A meeting bot can summarize a transcript. - A Slack AI can answer questions from threads. Useful. But in real company work, the hard problem is not just finding context. It is knowing which context should win. Because organizations are full of conflicting truth: - Slack says the scope changed. - Jira still has the old requirements. - Confluence has the previous architecture. - GitHub shows the new implementation. - The PM remembers a customer commitment. - The tech lead remembers a different tradeoff. - The EM remembers why the decision was made. So when an AI agent asks, “What should I do?” the answer is not sitting neatly in one place. It has to resolve context. - Which source is authoritative? - Which decision is newest? - Which owner has the final say? - Which document is stale? - Which ticket reflects current intent? - Which Slack thread changed the plan? - Which customer commitment constrains the implementation? - Which prior decision does this contradict? Without a resolver, the agent can retrieve more information and still make the wrong call. This is why I think “connect AI to all your tools” is not enough. Connection gives access. Resolution gives judgment. AI-native engineering teams need a context resolver that can map: - source → decision - decision → owner - owner → approval - approval → affected work - affected work → source-of-truth update That is the layer between raw company knowledge and useful agent action. Otherwise every agent becomes a confident intern with access to everything and authority over nothing. The future is not just more MCP servers, more search connectors, or more tool integrations. The future is a shared organizational context layer that helps agents and humans understand: - what is current - what is stale - what is authoritative - what needs review - what should happen next That is what we are building toward with Meetless.

Agent conversations are becoming organizational artifacts. This is a subtle shift, but I think it will matter a lot. Today, most AI agent conversations are treated as temporary work sessions. - An engineer asks Claude Code to investigate a bug. - A PM asks ChatGPT to analyze customer feedback. - A founder asks an internal agent to reason through pricing. - An EM asks an AI assistant to summarize delivery risk. The output might get copied somewhere. But the reasoning usually disappears. That is a problem. Because agent conversations increasingly contain real organizational value: - assumptions - tradeoffs - dead ends - decisions considered - context retrieved - risks identified - implementation rationale - questions that were answered - questions that remain unresolved In the old world, important reasoning was trapped in meetings, Slack threads, and people’s heads. In the new world, a lot of it will be trapped inside AI sessions. Same problem. New container. - If an AI coding session discovers that a Jira ticket is stale, that should not stay buried in the session. - If an agent finds that a Confluence page contradicts implementation reality, that should become visible. - If Claude Code makes an architectural assumption because the repo suggests one thing but the product decision says another, that tension matters. - If a PM uses an agent to explore a scope change, the final decision needs lineage. Not every agent thought should become company memory. That would create noise. But some agent conversations are clearly organizational artifacts. The hard part is deciding what should graduate: - Does this affect scope? - Does this affect architecture? - Does this affect another team? - Does this change a customer commitment? - Does this require approval? - Does this contradict prior decisions? - Does this update the source of truth? That is where I think AI-native engineering teams need new infrastructure. Personal agent sessions are not enough. The organization needs a way to turn important agent reasoning into shared coordination memory. Otherwise decision drift just moves one level deeper: from Slack threads into AI conversations. That is what we are exploring with Meetless. We are excited to show you how AI-native workflow should be done.

AI summaries are open-loop. AI coordination is closed-loop. Most AI meeting tools stop too early. They capture the conversation. They generate notes. They summarize decisions. They list action items. Then they leave the hard part to humans. Someone still has to ask: - Did the decision contradict a previous one? - Which Jira tickets are now stale? - Which Confluence pages need to change? - Who owns the follow-up? - Who needs to approve the decision? - Which team is affected? - Did the action item actually get routed? - Did the source of truth get updated? That is the problem with summaries. They are useful, but passive. A summary tells you what was said. It does not guarantee that the organization changed. That is open-loop. The loop ends at information. Closed-loop coordination is different. It does not stop at “here are the notes.” It continues: - decision detected - drift checked - owner identified - approval routed - source of truth updated - affected teams notified - organizational memory improved That is the difference between a meeting artifact and an operating system for work. In an AI-native company, the value is not just capturing more information. The value is making sure important information changes the state of the organization. A decision should not die in a summary. It should update the work graph. A blocker should not sit in meeting notes. It should route to the owner. A scope change should not live in a transcript. It should reconcile with Jira, Confluence, GitHub, and customer commitments. This is why I think “AI meeting notes” is only the entry point. The real category is AI coordination. Summaries help teams remember. Coordination helps teams act. That is what we are building toward with Meetless. Pilot with Meetless to experience how being AI-native changes your company.

Your coding agent is powerful alone. Your company needs a shared context layer. Claude Code can understand your repo. Cursor can help you move through implementation faster. Codex can generate tests, refactor code, and explain unfamiliar files. That is already a huge leap. But repo context is not company context. The codebase does not know everything the team has decided. It does not know that scope changed in Slack. It does not know that the PM promised a customer something different. It does not know that the architecture note in Confluence is stale. It does not know that another team depends on the old behavior. It does not know that the Jira ticket was never updated after the last alignment discussion. So the coding agent can be technically correct and organizationally wrong. That is the dangerous gap. AI coding agents make builders faster. But if they only reason from repo state, they can turn outdated assumptions into working software very quickly. The next unlock is not just better coding agents. It is giving those agents access to a shared context layer: - current decisions - decision lineage - owners - approvals - open questions - affected work - stale docs - cross-team dependencies - customer commitments Then the agent can ask better questions before implementation: - Is this still the current decision? - Has scope changed? - Which Jira ticket is authoritative? - Does this conflict with a prior decision? - Who owns this tradeoff? - Who needs to approve the change? That is the bridge I think AI-native engineering teams need. Personal coding agents make individuals faster. A shared context layer keeps the team aligned while everyone moves faster. Pilot with Meetless to experience the real AI-native workflow.

The single-player era of AI agents is ending. The first wave of AI agents made individuals powerful. Claude Code makes one engineer faster. Cursor makes one builder faster. ChatGPT makes one operator faster. Internal agents make one employee faster. That is real, but it is still mostly single-player. The next unlock is multiplayer. Because companies do not fail only because one person cannot move fast enough. They fail because teams lose shared context. - One engineer uses Claude Code to make an implementation decision. - A PM changes scope in Slack. - Jira still reflects the old plan. - Confluence has a stale architecture note. - GitHub shows the code changed, but not why. - Another team depends on an assumption nobody updated. Now everyone is individually faster, but collectively less synchronized. That is the problem with single-player agents. They make local execution faster, but they do not automatically create shared organizational memory. AI-native teams need a multiplayer layer: - shared context - decision lineage - owners - approvals - contradiction detection - source-of-truth updates - cross-tool coordination The question is no longer: - “How do I make one person 10x faster?” The better question is: “How do I make the team stay aligned while every person becomes 10x faster?” That is a different problem. It is not solved by another personal copilot. It requires a coordination layer that lets humans and agents operate from the same current understanding of the work.

AI-native engineering teams need memory, not more dashboards. Most engineering dashboards are just another place to look. - Sprint health. - Cycle time. - PR throughput. - Ticket status. - Burndown. - Incidents. - Blockers. Useful, but incomplete. A dashboard can show that something is late. It usually cannot tell you the decision history behind why it became late. A dashboard can show that a ticket moved. It usually cannot tell you which Slack thread changed the scope. A dashboard can show that work is blocked. It usually cannot tell you which owner is missing, which decision is unresolved, or which Confluence page is now stale. That is the core problem. Engineering teams do not just need visibility. They need organizational memory. Memory means the system knows: - What was decided. - Why it was decided. - Who decided it. - What changed afterward. - Which assumptions are now stale. - Which tickets are affected. - Which docs are outdated. - Which teams or owners need to be pulled in. - Without memory, dashboards become prettier status reports. They show symptoms. They do not preserve context. They do not detect drift. They do not reconcile contradictions. They do not route decisions. They do not update the source of truth. AI-native engineering teams need a layer that continuously captures and connects the work graph across Slack, Jira, Confluence, GitHub, customer commitments, and people. Not just “what is happening?” But: - What changed? - What does it contradict? - Who owns the decision? - What needs approval? - What should be updated? - What should happen next? That is the shift from dashboard to memory. Dashboards help humans inspect work. Memory helps AI coordinate work. That is what Meetless is about.

The future of sprint planning is not a better meeting. It is a continuously updated operating model. Most sprint planning meetings are overloaded because the team is trying to reconstruct reality in real time. - What changed since the last sprint? - What actually shipped? - What slipped? - Which tickets are stale? - Which Slack decisions changed scope? - Which Confluence pages no longer match reality? - Which customer commitments matter now? - Which dependencies are blocked? - Who needs to approve the new direction? That is too much context to rebuild live in a meeting. So sprint planning becomes a negotiation over incomplete memory. - The PM remembers one version. - The tech lead remembers another. - Jira shows a third. - Confluence is outdated. - Slack has the actual decision, buried in a thread from five days ago. Then the team spends the first half of planning rediscovering the state of work before they can even decide what to do next. That is not planning. That is context recovery. The better model is continuous. As work happens, the system should already know: - Which decisions changed. - Which tickets are affected. - Which docs are stale. - Which blockers are unresolved. - Which owners need to respond. - Which risks are increasing. - Which commitments may be impacted. - Which work is still aligned with the current plan. Then sprint planning changes. Instead of asking the team to reconstruct reality, the system brings a current operating view: - Here is what changed. - Here is what is drifting. - Here is what is blocked. - Here is what needs a decision. - Here is what should probably move into the next sprint. - Here is what should not. Humans still decide. But they should decide from a continuously updated model of the work, not from scattered memory. This is where I think AI-native engineering management is heading. Sprint planning becomes less of a meeting and more of a review of the current operating model. - Less archaeology. - More judgment. - Less status reconstruction. - More priority setting. - Less “what happened?” - More “what should we do now?” That is the direction with Meetless

AI coding agents make decision debt more dangerous. Most teams are focused on the obvious upside: - Code ships faster. - Tests get written faster. - Refactors become cheaper. - Prototypes turn into real features faster. That is real. But faster implementation exposes a deeper problem: - What happens when the decision behind the implementation is stale? - A Slack thread changes the scope. - The Jira ticket still reflects the old plan. - A Confluence page has the previous architecture. - The PM thinks one thing was agreed. - The tech lead implements based on another. Claude Code or Cursor helps generate the implementation quickly. Now the team has not just decision drift. It has decision drift converted into working software. That is much more expensive. In the old world, slow execution created time for misalignment to surface. - Someone might catch the issue in planning. - Someone might notice during grooming. - Someone might ask in standup. - Someone might flag it in review. In the AI-assisted world, that safety buffer shrinks. The wrong assumption can become a pull request in an afternoon. The wrong scope can become a shipped feature before the team has synchronized. The wrong architecture can spread through the codebase before the original decision is even updated. This is why AI-native engineering teams need more than coding agents. They need a coordination layer. Something that continuously checks: - Did the decision change? - Does Jira still match Slack? - Does Confluence still match implementation? - Who owns this change? - Who needs to approve it? - Which downstream work is affected? - Which source of truth is stale? The more powerful your builders become, the more dangerous unresolved decision debt becomes. AI will not only make good teams faster. It will also make misaligned teams create damage faster. That is the uncomfortable part. The next bottleneck is not code generation. It is keeping decisions synchronized while code moves faster than ever. This is what Meetless is about. I would love to connect with anyone who feels the same way.

Meetings are a symptom of a non-queryable organization. Most teams do not meet because meetings are the best way to work. They meet because the company’s context is scattered. - A decision happened in Slack. - The Jira ticket still says something else. - The Confluence page is stale. - The PM remembers one version. - The tech lead remembers another. - The engineering manager has to reconstruct reality from five different places. So the team schedules a meeting. Not to decide. To rediscover what already happened. That is the hidden cost of a non-queryable organization. When company memory is fragmented, meetings become the manual repair mechanism. Teams meet to answer basic questions: - What changed? - Who decided? - Why did we decide that? - Which work is affected? - Who needs to approve this? - What is blocked? - Which document is now wrong? - Which ticket needs to be updated? This is not collaboration. This is context reconstruction. And it is expensive. The better model is not “fewer meetings” as a discipline problem. The better model is making the organization queryable by default. Every important discussion should leave behind structured memory. Every decision should have context, ownership, and lineage. Every contradiction should be visible. Every stale source of truth should be surfaced. Every approval path should be clear. Then the meeting load drops naturally. Not because managers begged people to meet less. Because the system no longer requires humans to repeatedly reconstruct reality. That is the direction I’m exploring with Meetless. The thesis: engineering teams need a coordination memory layer that turns fragmented Slack, Jira, and Confluence activity into queryable context. I’m especially interested in how engineering managers handle repeated alignment meetings, decision drift, and status reconstruction.

The new engineering org chart: - Builder. - Owner. - Intelligence layer. That is where I think AI-native engineering teams are heading. The old org chart had too much human routing: - Engineers build. - Tech leads translate. - EMs collect status. - PMs align stakeholders. - Directors ask for rollups. - Meetings reconstruct reality. - Docs try to preserve memory. This made sense when context was fragmented and software moved at human speed. But AI changes the operating model. When builders have AI coding agents, implementation gets faster. When work happens across Slack, Jira, Confluence, GitHub, docs, and customer feedback, the company needs a persistent intelligence layer to keep the operating memory synchronized. That leaves three essential roles: 1. Builder The person closest to creation. They ship code, specs, workflows, experiments, prototypes, internal tools, customer fixes, and product changes. In an AI-native team, “builder” is not only an engineer. - PMs build. - Designers build. - Ops people build. - Founders build. The distinction is not “technical vs non-technical.” The distinction is: "Can you turn intent into working output?" 2. Owner The directly responsible person for an outcome. - Not a status collector. - Not a meeting router. - Not a passive approver. The owner makes judgment calls: - Is this the right priority? - Is the risk acceptable? - Who needs to be involved? - What tradeoff are we making? - What does success mean? - Should we ship, pause, escalate, or reverse? AI can support the owner, but it cannot fully replace ownership. Someone still needs to hold the outcome. 3. Intelligence layer This is the missing layer in most teams today. The intelligence layer watches the work graph: - Slack discussions - Jira tickets - Confluence pages - GitHub activity - decisions - dependencies - approvals - customer commitments Then it keeps the team synchronized: - detect changed decisions - catch contradictions - find missing stakeholders - route approvals - preserve memory - update the source of truth This is the work humans currently do through meetings, status reports, follow-ups, and tribal memory. That work should not sit inside a manager’s calendar forever. It should become infrastructure. The old engineering org chart was built around information routing. The new one should be built around outcome ownership. Builders create. Owners decide. The intelligence layer keeps everyone synchronized. That is the future we are building toward with Meetless. We are onboarding more engineering teams as design/pilot partners. If your team is dealing with decision drift, status-reporting fatigue, or too many alignment meetings, DM me. I’d be happy to show you what we’re building and see if it fits your workflow.

The middle manager role is being unbundled, not simply replaced. The lazy take is: “AI will replace managers.” I do not think that is the right frame. A lot of management work is not one job. It is a bundle of very different jobs: - Collecting status - Routing information - Remembering decisions - Following up on blockers - Reconciling Jira with reality - Making sure docs are updated - Finding who needs to approve what - Detecting when two teams are drifting apart - Coaching people - Making judgment calls - Handling conflict - Owning outcomes - Some of those jobs are human judgment work. - Some are coordination middleware. AI will attack the middleware first. Not because managers are useless. Because a lot of the manager’s calendar is spent doing work that only exists because the company’s context is fragmented. The EM asks for status because the system does not know what changed. The PM schedules an alignment meeting because the system does not know who disagrees. The tech lead repeats a decision because the system did not preserve the decision trail. The director asks for a rollup because the work graph is not queryable. That is the part AI should absorb. Continuous context capture. Decision memory. Contradiction detection. Stakeholder routing. Approval tracking. Source-of-truth updates. But the judgment layer remains human: - Is this the right priority? - Is the tradeoff acceptable? - Is the team overloaded? - Is this person struggling? - Is the conflict technical, organizational, or personal? - Do we need to escalate, defer, or make a hard call? The future manager is not a human status router. The future manager is closer to an outcome owner with an AI coordination layer underneath them. Less time reconstructing reality. More time making decisions that actually require judgment. That is the management shift I think AI-native engineering teams will go through. Not “replace managers.” Unbundle management. Automate the coordination middleware. Elevate the human judgment layer. We’re currently onboarding a few engineering teams as design/pilot partners for Meetless. If your team is dealing with decision drift, status-reporting fatigue, or too many alignment meetings, DM me. I’d be happy to show you what we’re building and see if it fits your workflow. If you manage an engineering team and this feels familiar, DM me. We’re opening a few Meetless pilot slots for teams dealing with decision drift and coordination overload.