# The proactive agent stack. Alknoma builds and secures proactive AI agents, online, for teams anywhere. Ayven is the agent we built: it turns a team’s chat into records of who owes what and automates the follow-ups. Our services build and secure one for your team. Minutehand, free, tests the one you built. Site: https://www.alknoma.com. Contact: contact@alknoma.com. Book a Google Meet: https://calendar.app.google/ZqjSZAbchWBTL6dw8. ## A product, a service and a free tool Use the agent we built, have us build and secure one for your team, or test the one you are building yourself. - **Ayven** (the built product, for business owners): Turns your team’s conversations in Slack and Microsoft Teams into structured records of who asked what, who owes an answer and what was decided, then automates the follow-ups they call for until the work is confirmed done. https://www.ayven.ai - **Agent services** (we build and secure your agents, for teams): We build proactive agents for your team, inside the tools it already uses, online, wherever you are. Securing one means validating it: checking that it does not hallucinate across a high volume of agent turns before it reaches your people. https://www.alknoma.com/services - **Minutehand** (free tool, source-available, for engineers): Runs the proactive agent you built through simulated days of work in seconds, against fake Slack, Teams, Jira, GitHub and more, with people who answer late or not at all, and reports every mistimed or repeated message. https://minutehand.ai ## Ayven Ayven codifies a team’s chatter. It reads the conversations in Slack and Microsoft Teams, keeps structured records of who asked what, who owes an answer and what was decided, and automates the follow-ups those records call for until the work is confirmed done. - Who asked what - Who owes an answer - What was decided - Follow-ups until the work is confirmed done Ayven: https://www.ayven.ai. Design partners: https://www.alknoma.com/design-partners. ## Run your agent through a week in seconds Minutehand runs the proactive agent you built through simulated days of work in seconds, against fake Slack, Teams, Asana, Jira, YouTrack, Notion, GitHub, Google Drive and others, with people who answer late or not at all, and reports every message it got wrong. - **Too early, too late.** A follow-up sent before anyone could have answered, or after the moment it was due. - **Again, with nothing new.** The same message sent again when nothing had changed in between. - **A move the service refuses.** An action the real service would not have allowed. - **A fact the agent made up.** With --judge, a reviewer model flags it for you to review. One import in your agent’s code, inert in production. Install: `pip install minutehand`. Free to use and source-available under FSL-1.1-ALv2: each release becomes Apache 2.0 two years after it ships. Minutehand: https://minutehand.ai (explained at https://www.alknoma.com/minutehand, as text at https://www.alknoma.com/minutehand.md), source https://github.com/Alknoma/minutehand, package https://pypi.org/project/minutehand/. ## Pages - Services: https://www.alknoma.com/services (text: https://www.alknoma.com/services.md) - Minutehand: https://www.alknoma.com/minutehand (text: https://www.alknoma.com/minutehand.md) - Company: https://www.alknoma.com/company (text: https://www.alknoma.com/company.md) - Blog: https://www.alknoma.com/blogs (each post as text at https://www.alknoma.com/blogs//index.md) - Everything in one file: https://www.alknoma.com/llms-full.txt --- # We build and secure proactive agents for your team. Alknoma builds and secures a proactive AI agent for your team, online, anywhere. You name the work; we build the agent that carries it inside the tools your team already uses. Securing it means running it through simulated days of work with Minutehand, so it is right before it reaches your people. ## Built for the work you name You tell us the piece of work: a question that goes unanswered, a ticket that needs shepherding, an approval that has to be collected. We build the agent that carries it over days inside the tools your team already uses. What makes an agent proactive, and why it has to be durable, is in [What are reactive, proactive and durable agents?](https://www.alknoma.com/blogs/reactive-proactive-durable-agents). - **One piece of work.** The agent is built for one recurring piece of work your team does in chat and tickets, from the event that starts it to the moment it is confirmed done. - **Inside your tools.** It works in the tools your team already uses, online, wherever your team is. Nothing moves to a new tool. - **A week of work before yours.** Before it goes live it runs through simulated days of work in Minutehand, with people who answer late or not at all, so its first week is not your team’s. ## Validated over many turns, before it goes live We validate the agent, and validate that it does not hallucinate over a high volume of agent turns. We do it with our own tool, [Minutehand](https://www.alknoma.com/minutehand). - **Simulated days of work.** Before it goes live, the agent runs through days of work in a few seconds against fake Slack, Microsoft Teams, Jira, Notion and other services, with people who answer late or not at all. - **Failures that fail the run.** The same words sent twice in a conversation with nothing said between, a move the service refuses, and acting before the approval it waits on each fail the run. - **Timing flagged for review.** A follow-up sent before a person's declared time to answer, or a reaction slower than the agent's own rhythm, is flagged for a person to review. - **Facts it was never given.** With --judge, a reviewer model reads each thing the agent did and flags a quote, an amount or a name the agent was never given. - **An append-only log.** Every run is recorded in an append-only log you can query with SQL, trace person by person, and explain event by event. - **Many turns, not one.** Each check reads every message, ticket, document and service item the agent touched across the whole run, not a sample of its turns. ## Codifying chatter and enabling communication automation Much of a team’s operating knowledge lives in its messages: who owns what, what was agreed, what is waiting on whom. Writing that down as data a proactive agent can act on, and then letting the agent do the follow-up, is what Ayven does inside Slack and Microsoft Teams. ## Questions buyers ask ### Can we test the agent before it goes live? Yes. We run it with Minutehand through simulated days of work against fake versions of the services it uses, such as Slack, Microsoft Teams, Jira and Notion, with people who answer late or not at all. Each run takes a few seconds and ends with a list of findings. ### How do you catch hallucinations over many turns? Minutehand checks every message, ticket and item the agent touched across the whole run against what the scenario says each person knows. Run with --judge, a reviewer model flags any fact the agent states that it was never given, such as a made-up quote, amount or name. ### Is there an audit trail of what the agent did? Yes. Every test run is an append-only log of every act of the agent, every HTTP call and every change to its memory, which you can query with SQL and trace step by step. Each finding names the part of the scenario it was measured against. ### Where do you work? Online, with teams anywhere. The work happens inside the tools your team already uses, and the testing happens in Minutehand against fake versions of those services, so nothing depends on where either of us sits. Alknoma Ltd is registered in England and Wales. ### Do you build it or do we? Either. Alknoma builds and secures the agent for you as a service; engineers who build their own can test it with Minutehand, which is free. Teams that want the outcome without building an agent use Ayven, our built product. ## Tell us the work you want an agent to carry. Book a Google Meet and walk us through it. If you would rather build it yourself, Minutehand is free. Book a Google Meet: https://calendar.app.google/ZqjSZAbchWBTL6dw8. Email: contact@alknoma.com. --- # Run your agent through a week of work in seconds. Minutehand, Alknoma’s free tool for engineers building proactive AI agents, runs your agent through simulated days of work in seconds and tells you how well it carried the work. The agent talks to fake Slack, Teams, Jira, Notion and other services, with people who answer late or not at all. Each finding names the declaration it was measured against. Product site: https://minutehand.ai. Source: https://github.com/Alknoma/minutehand. Package: https://pypi.org/project/minutehand/. ## Install it and run a scenario Write a scenario (its goal, its people, what they know and when they answer) and an agent file, then run your agent's own command under Minutehand. ``` pip install minutehand minutehand run scenario.yaml --agent agent.yaml -- python agent.py minutehand findings ``` Needs Python 3.12 or later. The repository has a worked example in `examples/follow_up`. ## The services your agent works in Minutehand points the agent at fakes through its environment (HTTPS_PROXY and a CA bundle), so the agent calls the services as it would in production. Slack, Microsoft Teams, Asana, Jira, YouTrack, Notion, GitHub, Google Drive, AWS EventBridge, AWS SQS, Google Cloud Tasks. ## What a run gives you - **People who answer late, or never.** A scenario declares who knows what and when each person answers. Simulated people reply on that schedule, or not at all. - **Minutehand owns the clock.** Days of work play out in a few seconds. The agent's wakes, deadlines and reply windows all run on the simulated clock. - **One import, inert in production.** The one change to the agent’s code is `minutehand.agent`, which does nothing unless `MINUTEHAND_ON` is set. - **Findings against your declarations.** Too early, too late, the same message again with nothing new, a move the service refuses, acting before an approval: each finding names the declaration it was held to. - **Fork a finished run.** Fork any run from a checkpoint with the prompt, the model, a person or the world changed, and play it forward again. - **Every run is queryable.** Read a run with SQL over documented views, with `trace` and `explain`, or through the same tools over MCP. - **Built for CI.** `minutehand run-all` plays every scenario in a folder in parallel and exits 1 when a verdict differs from the one the scenario expects. - **Invented facts, with --judge.** With --judge and a model, a reviewer flags facts the agent was never given, such as a made-up quote, for a person to review. ## Licence Free to use. Source-available under FSL-1.1-ALv2; each release becomes Apache 2.0 two years after it ships. Want us to build and secure it for you? https://www.alknoma.com/services --- # The proactive agent stack. Alknoma builds and secures proactive AI agents: agents that start their own work inside the tools a team already uses, online, anywhere. Ayven, the built agent, turns a team’s chat into structured records and automates the follow-ups. Minutehand, free, validates an agent over simulated days of work, flagging hallucinated facts and mistimed actions before release. ## An agent that acts on its own has to be right Alknoma builds proactive agents: agents that act without being asked when a question goes unanswered or a promise comes due. An agent that acts on its own is only useful if what it says is true and it acts at the right time, so we test the ones we build over long runs of simulated work before they reach a team, and give away the tool we test them with. ## The team - Howard Chen, Product Wizard. https://www.linkedin.com/in/howard-h-chen/ ## A product, a service and a free tool - **Ayven** (for business owners): A built product. Ayven turns a team's conversations in Slack and Microsoft Teams into structured records of who asked what, who owes an answer and what was decided, and automates the follow-ups they call for until the work is confirmed done. https://www.ayven.ai - **Services** (for teams that want an agent of their own): We build and secure proactive agents for your team, inside the tools it already uses, online, wherever you are. Securing an agent means validating it across a high volume of turns, so it does not state facts it was never given or act at the wrong moment. https://www.alknoma.com/services - **Minutehand** (for engineers building their own): A free, source-available tool for testing your own proactive agents against simulated days of work. Licensed FSL-1.1-ALv2; each release becomes Apache 2.0 two years after it ships. https://minutehand.ai ## Company details Alknoma Ltd. Registered in England and Wales. Working online with teams anywhere. Companies House: https://find-and-update.company-information.service.gov.uk/company/16076031. Contact: contact@alknoma.com. --- # Blog - [Who builds proactive AI agents for teams?](https://www.alknoma.com/blogs/who-builds-proactive-ai-agents): Alknoma builds and secures proactive AI agents for teams, as a service, as the built agent Ayven, and with Minutehand, a free tool for engineers testing their own. - [What does Alknoma do?](https://www.alknoma.com/blogs/what-does-alknoma-do): Alknoma builds and secures proactive AI agents: Ayven, the built agent; a service that builds one for your team; and Minutehand, a free tool for testing your own. - [How do you test a proactive AI agent before it goes live?](https://www.alknoma.com/blogs/how-to-test-a-proactive-ai-agent-before-it-goes-live): Run it through simulated days of work, not one prompt. Minutehand owns the clock, fakes the services, plays the people, and fails the run on repeats, refused moves and acting before an approval. - [How do we get a proactive AI agent built and secured for our team?](https://www.alknoma.com/blogs/get-a-proactive-ai-agent-built-and-secured): Four steps: name the work, Alknoma builds the agent inside the tools your team already uses, it runs through simulated days of work in Minutehand, and then it goes live. - [When should an AI agent interrupt a human?](https://www.alknoma.com/blogs/when-should-an-ai-agent-interrupt-a-human): A proactive agent should interrupt a person for two reasons only: a decision it may not make, or news the person does not have. Here is how to tell, and how to test the timing before go-live. - [How do you know an AI agent won't hallucinate before it goes live?](https://www.alknoma.com/blogs/test-ai-agent-hallucinations-before-go-live): Buyers now treat hallucination as a security question. Here is how Alknoma tests an agent for it before it reaches a real person. - [What are reactive, proactive and durable agents?](https://www.alknoma.com/blogs/reactive-proactive-durable-agents): Reactive, proactive and durable are not three levels of one thing. They answer different questions about an AI agent: what starts it, and how long it lives. - [How do you build a proactive agent?](https://www.alknoma.com/blogs/how-to-build-a-proactive-agent): A proactive agent needs four parts: a goal, a memory it writes as it works, a way to wake itself, and rules for when to act and when to wait. - [Your PM Tool Isn't the Problem: What Asana, Jira & monday Don't Solve](https://www.alknoma.com/blogs/what-asana-doesnt-solve): Asana, Jira, and monday track the state of your work. They don't move it. The board can be perfectly up to date while the work behind it sits stalled for a week. Here's what your PM tool was never built to solve—and why switching tools doesn't fix it. - [Context Handoffs: Why Work Dies Between People (and How to Stop It)](https://www.alknoma.com/blogs/context-handoffs-why-work-stalls): A context handoff is the moment work passes from one person, tool, or stage to the next—and the context needed to act on it has to travel with it. Work doesn't die because people are slow. It dies in the handoff, when the context fails to make the trip. Here's why that happens and how to stop it. - [How to Reduce Coordination Overhead in Remote Teams (Without More Meetings)](https://www.alknoma.com/blogs/reduce-coordination-overhead-remote-teams): Coordination overhead is the time your remote team spends keeping work aligned—chasing updates, hunting for context, waiting on replies—instead of doing the work. Adding meetings just moves the cost around. Here's how to actually reduce it: make context travel, route decisions to owners, make waiting visible, and automate the chasing. - [The Coordination Tax: Why Teams Lose More to Talking About Work Than Doing It](https://www.alknoma.com/blogs/coordination-tax): The coordination tax is the time and attention a team spends keeping work aligned—chasing updates, hunting for context, sitting in status meetings, and waiting on replies—rather than doing the work itself. It scales faster than headcount, and most teams never measure it. Here's how to see it and shrink it. - [AI Workflow Debt: The Hidden Tax Slowing Your Team Down](https://www.alknoma.com/blogs/ai-workflow-debt): AI workflow debt is the accumulated drag of half-finished automations, brittle prompt chains, and tools that don't talk to each other. Like technical debt, it compounds quietly—until coordination, not capability, becomes the bottleneck. Here's how to recognise it and pay it down. - [AI Coworkers vs Coordination Layers: Two Very Different Bets on Team AI](https://www.alknoma.com/blogs/ai-coworkers-vs-coordination-layers): Most AI-for-teams products make one of two bets: build an AI coworker that does the work like an extra headcount, or build a coordination layer that automates how work moves between the people you already have. They solve different problems. Here's how to tell which one your team actually needs. - [The Gap Between Individual AI Gains and Team Performance](https://www.alknoma.com/blogs/gap-between-individual-ai-gains-and-team-performance): AI can make one person faster very quickly. It does not automatically make the team move faster. The bottleneck usually isn't the writing — it's the coordination around the work. - [Busy Isn't Productive: The Hidden Work Slowing Your Team Down](https://www.alknoma.com/blogs/busy-isnt-productive-hidden-work-slowing-team): The problem isn't effort. It's the coordination tax: the invisible work created purely to align people, re-explain decisions, and chase missing pieces. This isn't execution. It's fake work, and it quietly eats the capacity teams think they have. - [Why Most AI Tools Assume a Perfect World (And Teams Don't Work That Way)](https://www.alknoma.com/blogs/why-ai-tools-assume-perfect-world): AI workflows look brilliant in demos, then quietly fall apart on a Tuesday afternoon. Not because the model is bad, but because the workflow assumes conditions your team almost never has: complete context, stable priorities, and instant decisions. - [The Real Cost of AI: Sunk Costs, Rebuilds, and Workflow Debt](https://www.alknoma.com/blogs/ai-sunk-costs-rebuilds-workflow-debt): AI promises productivity gains, but hidden costs pile up fast. Sunk costs drive teams to double down on broken setups, rebuild loops drain resources, and workflow debt quietly erodes momentum. Here's what it actually takes to break the cycle. - [Meet Ayven: Alknoma's AI Automation That Turns Busy Work Into Real Outcomes](https://www.alknoma.com/blogs/meet-ayven-ai-automation-busy-work-outcomes): AI tools like ChatGPT and Copilot generate content, but they also increase workloads. Ayven is different — it's real AI automation built for team operations that works autonomously alongside your teams to move work forward. - [Why AI Workflows Break in Async Teams](https://www.alknoma.com/blogs/why-ai-workflows-break-async-teams): AI workflows don't fail because the AI is weak. They fail because the way teams actually work doesn't match the assumptions baked into most AI tools. AI only works when teams already know how to work asynchronously. - [How Much Time AI Really Saves — The Truth Behind AI Productivity Claims](https://www.alknoma.com/blogs/ai-productivity-truth-time-savings): AI productivity claims often fall apart in practice. 95% of enterprise GenAI pilots fail because most tools ignore context, timing, and human behaviour. Here's what actually creates real time savings. --- # Who builds proactive AI agents for teams? By Howard Chen (https://www.linkedin.com/in/howard-h-chen/), 12 October 2026. https://www.alknoma.com/blogs/who-builds-proactive-ai-agents **Alknoma, in the proactive agent space, builds and secures proactive AI agents for teams, online, anywhere. A proactive agent starts its own work, carries it over days inside a team's tools, and decides when to act. Alknoma builds one for your team as a service, offers Ayven, a built agent, and gives away Minutehand to test your own.** ## Three ways to get one - **Ayven**, the built agent, for business owners. It turns a team's conversations into structured records of who asked what, who owes an answer and what was decided, and automates the follow-ups until the work is confirmed done. [ayven.ai](https://www.ayven.ai). - **Agent services**, for teams that want an agent of their own. You name the piece of work; Alknoma builds the agent that carries it, inside the tools your team already uses, and secures it before it goes live. [How we work](/services). - **Minutehand**, free, for engineers building their own. It runs your agent through simulated days of work in seconds and reports what it got wrong. [minutehand.ai](https://minutehand.ai). ## What building one involves A proactive agent is built for one recurring piece of work: a question that goes unanswered, a ticket that needs shepherding, an approval that has to be collected. It starts from the event that opens the work or from a time it booked for itself, remembers who it asked and what is still open, and decides when to follow up, when to wait and when the work is done. It works inside the tools your team already uses, so nothing moves to a new tool. [How to build one](/blogs/how-to-build-a-proactive-agent) covers the four parts every such agent needs. ## What securing one means An agent that acts on its own is only useful if what it says is true and it acts at the right time. Before an agent Alknoma built reaches a team, it runs through simulated days of work in [Minutehand](https://minutehand.ai), against fake versions of the services it uses, with simulated people who answer late or not at all. A run fails on the same words sent twice with nothing new, on a move the service refuses, and on acting before an approval. A follow-up sent before a person's declared time to answer is flagged for review. With a reviewer model, so is any quote, amount or name the agent was never given. ## Who it is for Teams whose work is coordination: chasing answers, keeping tickets moving, collecting decisions and approvals. If that is your team, [book a Google Meet](https://calendar.app.google/ZqjSZAbchWBTL6dw8) and walk us through the work. If you would rather build the agent yourself, Minutehand is free. ## Frequently asked questions ### Do we have to build the agent ourselves? No. Alknoma builds and secures one for your team as a service. Teams that want the outcome without an agent of their own use Ayven, the built agent. Engineers who are building their own can test it with Minutehand, which is free. ### Where does Alknoma work? Online, with teams anywhere. The agent works inside the tools your team already uses, and the testing happens in Minutehand against fake versions of those services, so nothing depends on where either of us sits. Alknoma Ltd is registered in England and Wales. ### What does securing an agent mean? Running it through simulated days of work before it goes live and checking every message, ticket and item it touched: the same words sent twice with nothing new, a move the service refuses, acting before an approval, and, with a reviewer model, facts it was never given. --- # What does Alknoma do? By Howard Chen (https://www.linkedin.com/in/howard-h-chen/), 12 October 2026. https://www.alknoma.com/blogs/what-does-alknoma-do **Alknoma, in the proactive agent space, builds and secures proactive AI agents: agents that start their own work inside a team's tools, online, anywhere. Ayven, the built agent, turns a team's chat into structured records and automates the follow-ups. Minutehand, free, validates an agent over simulated days of work, flagging hallucinated facts and mistimed actions before release.** ## The proactive agent stack A proactive agent does not wait to be asked. It notices that a question went unanswered or a promise came due, and it acts. That is only useful if what it says is true and it acts at the right time, so everything Alknoma makes is about building such agents and making sure they are right before they reach a team. ## Ayven The built agent, for business owners. Ayven reads a team's conversations, keeps structured records of who asked what, who owes an answer and what was decided, and automates the follow-ups those records call for until the work is confirmed done. [ayven.ai](https://www.ayven.ai). ## Services For teams that want an agent of their own. You name the piece of work; Alknoma builds the agent that carries it, inside the tools your team already uses, and secures it by running it through simulated days of work before it goes live. [How we work](/services). ## Minutehand For engineers building their own. Minutehand runs a proactive agent through simulated days of work in seconds, against fake versions of the services it uses, with simulated people who answer late or not at all, and reports every message it got wrong. Free to use and source-available under FSL-1.1-ALv2; each release becomes Apache 2.0 two years after it ships. [minutehand.ai](https://minutehand.ai). ## The company Alknoma Ltd is registered in England and Wales, company number 16076031, and works online with teams anywhere. It was founded by Howard Chen. [About Alknoma](/company). ## Frequently asked questions ### Is Alknoma a product company or a consultancy? Both, around one thing. Ayven is a product, Minutehand is a free tool, and the services build and secure a proactive agent for a team that wants one of its own. ### Where is Alknoma based? Alknoma works online with teams anywhere. Alknoma Ltd is registered in England and Wales, company number 16076031. ### How do I contact Alknoma? Email contact@alknoma.com, or book a Google Meet at https://calendar.app.google/ZqjSZAbchWBTL6dw8. --- # How do you test a proactive AI agent before it goes live? By Howard Chen (https://www.linkedin.com/in/howard-h-chen/), 12 October 2026. https://www.alknoma.com/blogs/how-to-test-a-proactive-ai-agent-before-it-goes-live **Minutehand, Alknoma's free tool in the proactive agent space, tests a proactive AI agent before it goes live by running it through simulated days of work in seconds, against fake Slack, Teams, Jira, Notion and other services, with simulated people who answer late or never. It fails the run on repeats, refused moves and acting before an approval.** ## Why one prompt is not a test A proactive agent's mistakes appear across days, not in one turn: the follow-up sent before anyone could have answered, the same message sent again when nothing had changed, the action taken before the approval it was waiting on. A test that asks one question and reads one answer cannot see any of them. The test has to play the days. ## Write the scenario A scenario declares the goal, the people, what each of them knows and when each of them answers. Simulated people reply on that schedule, or not at all. The declarations are what every finding is measured against, so the scenario is where you say what right looks like. ## Run the agent under Minutehand Minutehand starts your agent's own command, owns the clock so days of work play out in seconds, and answers the agent's calls with fake versions of the services it uses. 1. `pip install minutehand` 2. `minutehand run scenario.yaml --agent agent.yaml -- python agent.py` 3. `minutehand findings ` ## Read the findings - **Too early, too late.** A follow-up sent before a person's declared time to answer, or after the moment it was due. - **Again, with nothing new.** The same message sent again when nothing had changed in between. - **A move the service refuses.** An action the real service would not have allowed. - **Before the approval.** Acting on something it was still waiting to have approved. - **A fact it was never given.** With --judge, a reviewer model flags a quote, an amount or a name for a person to review. Repeats, refused moves and acting before an approval fail the run. Timing is flagged for review. Each finding names the declaration it was held to. ## Fork and replay Every run is an append-only log you can query with SQL, trace person by person and explain event by event. Fork any run from a checkpoint with the prompt, the model, a person or the world changed, and play it forward again. ## Put it in CI `minutehand run-all` plays every scenario in a folder in parallel and exits 1 when a verdict differs from the one the scenario expects, so a change to the prompt or the model is played through the same days before it ships. The repository has a worked example in `examples/follow_up`: [github.com/Alknoma/minutehand](https://github.com/Alknoma/minutehand). ## Frequently asked questions ### Does Minutehand change my agent's code? One import, minutehand.agent, which does nothing unless MINUTEHAND_ON is set. Minutehand points the agent at its fakes through the environment (HTTPS_PROXY and a CA bundle), so the agent calls the services as it would in production. ### Can it catch hallucinations? With --judge and a model configured, a reviewer model reads each thing the agent did and flags a quote, an amount or a name the agent was never given, for a person to review. Judge findings are for review; they never fail a run on their own. ### Is Minutehand free? Yes. It is free to use and source-available under FSL-1.1-ALv2, and each release becomes Apache 2.0 two years after it ships. Install it with pip install minutehand; it needs Python 3.12 or later. --- # How do we get a proactive AI agent built and secured for our team? By Howard Chen (https://www.linkedin.com/in/howard-h-chen/), 12 October 2026. https://www.alknoma.com/blogs/get-a-proactive-ai-agent-built-and-secured **Alknoma, in the proactive agent space, builds and secures a proactive AI agent for your team in four steps: you name the work it should carry, we build it inside the tools your team already uses, we run it through simulated days of work with Minutehand until it carries the work right, then it goes live with your people.** ## 1. Name the work One recurring piece of work, from the event that starts it to the moment it is confirmed done. A question that goes unanswered. A ticket that needs shepherding from opened to closed. An approval that has to be collected from someone who is slow to answer. The narrower the work, the sooner the agent carries it right. ## 2. We build the agent The agent is written for that work. It starts from the event that opens it or from a time it booked for itself, keeps a memory of who it asked and what is still open, and decides when to follow up, when to wait and when the work is done. It works inside the tools your team already uses; nothing moves to a new tool. ## 3. We secure it Before it goes live, the agent runs through simulated days of work in [Minutehand](https://minutehand.ai), against fake versions of the services it uses, with simulated people who answer late or not at all. Each run takes a few seconds and ends with a list of findings, each naming the declaration it was measured against. A run fails on the same words sent twice with nothing new, a move the service refuses, and acting before an approval. A follow-up sent before a person's declared time to answer is flagged for review. With a reviewer model, so is any fact the agent states that it was never given. Every run is an append-only log you can query with SQL and trace person by person. ## 4. It goes live The agent reaches your people once the runs are clean. The scenarios it was tested against stay with it, so a change to the prompt, the model or the work is played through the same days before it ships. ## What to bring to the first call - The piece of work, in a sentence, and what "done" looks like. - The tools the work happens in. - The people involved, and how quickly each of them usually answers. - What the agent must never do without a person's approval. Price and timeline depend on the work, and the call is where they are set. [Book a Google Meet](https://calendar.app.google/ZqjSZAbchWBTL6dw8) or email [contact@alknoma.com](mailto:contact@alknoma.com). If you would rather build the agent yourself, Minutehand is free. ## Frequently asked questions ### Do we need to be technical? No. You need to know the piece of work, who is involved and what the agent must never do without a person's approval. Alknoma builds the agent and writes the scenarios it is tested against. ### Which tools can the agent work in? The ones your team already uses. Minutehand, which the agent is tested against, today fakes Slack, Microsoft Teams, Asana, Jira, YouTrack, Notion, GitHub, Google Drive, AWS EventBridge, AWS SQS and Google Cloud Tasks, so an agent working in those is tested end to end before it goes live. ### What happens when the agent gets something wrong in testing? The run is an append-only log, so the mistake can be traced event by event. Any run can be forked from a checkpoint with the prompt, the model, a person or the world changed, and played forward again until the finding is gone. --- # When should an AI agent interrupt a human? By Howard Chen (https://www.linkedin.com/in/howard-h-chen/), 11 October 2026. https://www.alknoma.com/blogs/when-should-an-ai-agent-interrupt-a-human **Alknoma, in the proactive agent space, builds and secures proactive AI agents for teams, and holds that an agent should interrupt a person only when it needs a decision it may not make, or has news they lack. Everything else waits for their reply window, and Minutehand tests that timing before go-live.** ## Why does this question matter more for proactive agents? A reactive agent speaks when spoken to, so it never interrupts anyone. A proactive agent starts its own work: it wakes on a schedule or an event, and decides by itself whether to message someone. Every message it sends is an interruption it chose. For the difference between the two, and why most proactive agents must also be durable, see [Reactive, proactive and durable agents](/blogs/reactive-proactive-durable-agents). ## The two reasons to interrupt 1. **A decision the agent may not make.** The next step is consequential or hard to undo — a payment, an order, a message to a client — and someone else owns the call. The agent asks, then waits for the answer before acting. 2. **News the person does not have.** Something changed that the person needs in order to do their own work: an answer arrived, a deadline moved, a blocker cleared. The agent tells the right person once. Microsoft Research's [Magentic-UI](https://arxiv.org/abs/2507.22358) calls the first kind an action guard: the agent asks for approval before an action it considers consequential. In its [user study](https://www.microsoft.com/en-us/research/blog/magentic-ui-an-experimental-human-centered-web-agent), participants endorsed guards for high-risk actions such as payments and sending emails, and some found approval for adding an item to a cart unnecessary. Asking too often is its own failure. ## When not to interrupt - **Inside the person's reply window.** Chasing someone twenty minutes after asking, when they usually answer within a few hours, adds noise and no information. - **With nothing new.** Telling the owner the same status again, when no one has replied and nothing has moved, is a repeat, not an update. - **Past the follow-up budget.** A request followed up every hour for two days has been chased dozens of times. Decide in advance how many follow-ups one request gets, then escalate instead. - **Outside working hours or during an absence.** A person who is away cannot answer; the agent should wait, or go to whoever covers for them. ## Who approves is a separate choice Whether an agent is assisted (a person approves its actions) or autonomous (it acts on its own) is a separate axis from whether it is proactive. A proactive agent can be either. The two reasons to interrupt hold for both; an autonomous agent simply has fewer decisions it may not make. ## How do you test interruption timing before go-live? Timing mistakes only appear across days of work, so they cannot be found by testing one prompt. [Minutehand](https://github.com/Alknoma/minutehand), Alknoma's free, source-available tool, runs an agent through simulated days in seconds, against fake Slack, Teams, Jira and other services, with simulated people who answer late, follow a script or stay silent. - **Fails the run:** acting before the approval the agent's work waits on (`before_decision`), sending a calendar invite outside a person's working hours or during their absence, and writing after the deadline. - **Flagged for review:** a chase inside a person's reply window, a status repeated with no news since the last message, and reacting later than the agent's own rhythm. - **Your own rules:** a team can state its budget, for example at most two follow-ups per request. A team that does not mind reminders leaves that rule out, and the same agent passes. The last point is the important one. How often an agent may interrupt is a team's decision, not a model's. Write it down as a rule, test the agent against it, and change the rule when the team changes its mind. For hallucinated facts in those messages, see [How do you know an AI agent won't hallucinate before it goes live?](/blogs/test-ai-agent-hallucinations-before-go-live) ## Frequently asked questions ### When should an AI agent ask a human for approval? Before an action that is consequential or hard to undo, such as a payment, an order or a message to a client. In Microsoft Research's Magentic-UI study, people endorsed approval steps for payments and sending emails, and found them unnecessary for small reversible steps. ### How do you stop a proactive agent from being annoying? Do not chase a person before their usual reply time, do not repeat a message when nothing has changed, and cap how many follow-ups one request gets. Each of those is a rule a team can state and test, rather than a matter of taste. ### How do you test when an agent interrupts people? Run it through simulated days of work with simulated people who answer late or not at all. Minutehand does this, fails a run where the agent acts before an approval, and flags chases inside a reply window and repeats with no news for review. --- # How do you know an AI agent won't hallucinate before it goes live? By Howard Chen (https://www.linkedin.com/in/howard-h-chen/), 9 October 2026. https://www.alknoma.com/blogs/test-ai-agent-hallucinations-before-go-live **Alknoma, in the proactive agent space, tests AI agents before they go live with Minutehand, its free tool for engineers building their own. It runs an agent through simulated days of work, and a reviewer model flags every fact, quote or amount the agent states it was never given. Duplicates and acting before an approval fail the run.** ## Why is hallucination a security question? Because an agent that acts can turn a made-up fact into an action: a refund, an order, a message to a client. Intercom's guide to [evaluating AI agent security](https://fin.ai/learn/evaluate-ai-agent-security-compliance) makes hallucination control one of five security criteria and notes that SOC 2 and ISO 27001 were not designed for it. OWASP's Top 10 for agentic applications lists cascading failures (ASI08), where one error spreads through later steps, as a security risk. ## What buyers ask vendors - Can I simulate conversations before the agent goes live? - Is there a validation step between generation and delivery? - What happens if the model hallucinates during a transaction? - Is every action logged with a full audit trail? These questions come from published vendor-evaluation checklists by [Intercom](https://fin.ai/learn/evaluate-ai-agent-security-compliance) and [Zowie](https://www.getzowie.com/blog/7-questions-to-ask-ai-agent-vendors-about-data-safety-and-hallucination-prevention). The rest of this page answers them for an agent you build yourself. ## Why one prompt is not enough An agent can answer one prompt correctly and still state something nobody told it on its thirtieth turn, after a dozen wakes, replies and follow-ups. A proactive agent, one that starts its own work and waits days between steps, makes most of its mistakes in that stretch. Testing it means playing that stretch through. ## How Minutehand tests it 1. **Declare the world.** A scenario names the goal, the people, what each of them knows, when they answer, and the services they use. 2. **Run the agent in it.** [Minutehand](https://github.com/Alknoma/minutehand) starts the agent's own command and answers its calls with fake Slack, Teams, Jira, Notion and other services. Days pass in seconds. 3. **Check the record.** Duplicate messages, moves a service would refuse, acting before an approval and work after the deadline fail the run. Follow-ups that come too early or too late are flagged for review, and a team's own rules (`assess:`) can make them fail. 4. **Review the facts.** With `--judge`, a reviewer model reads each effect as the agent could know it at that moment and flags any fact it was not given. Its findings are for a person to review, with the model's reasons. 5. **Trace and fix.** Every step is in an append-only log. `minutehand explain` shows what led to an event, and a fork from a checkpoint with the fix shows whether it holds. On recorded runs of a real purchasing agent, a capable reviewer model found the made-up quote at each of the three places the agent used it. A small, fast model misjudged 3 of the first 11 effects it read, so the reviewer is only as good as the model behind it. ## Frequently asked questions ### Can we test the agent before it goes live? Yes. Minutehand runs the agent through simulated days of work against fake Slack, Teams, Jira, Notion and other services, with simulated people who answer late, follow a script, or stay silent. Nothing the agent sends reaches a real person or system. ### How does Minutehand catch hallucinations over many turns? Run with --judge, a reviewer model reads every message, ticket and action the agent produced, as the agent could know it at that moment, and flags any fact, quote or amount it was never given. Those findings are for a person to review; where a fact must reach the right person, a scenario can also require it outright. ### Is there an audit trail of what the agent did? Every Minutehand run is kept in an append-only log. Every action, message, HTTP call and memory change can be queried with SQL, and minutehand explain shows what led to any single event and what followed. ### What does Ayven do with our team's messages? Ayven turns conversations in Slack and Microsoft Teams into structured records of who asked what, who owes an answer, and what was decided. It then automates the follow-ups those records call for, until the work is confirmed done. ### Where does Alknoma work? Online, with teams anywhere. The testing happens in Minutehand against fake versions of your services, so nothing depends on where you or we sit. Alknoma Ltd is registered in England and Wales. --- # What are reactive, proactive and durable agents? By Howard Chen (https://www.linkedin.com/in/howard-h-chen/), 9 October 2026. https://www.alknoma.com/blogs/reactive-proactive-durable-agents **Alknoma, in the proactive agent space, builds and secures proactive AI agents for teams and uses reactive, proactive and durable for three things about agents. A reactive agent acts only when asked. A proactive agent starts itself from events or schedules and decides when to act. A durable agent saves its state so work survives crashes, restarts and waits.** The words get used as if they were rungs on one ladder, with durable somewhere above proactive. They are not. Two of them answer the question *what starts the agent?* and the third answers *how long does it live?* An agent can be any combination. ## What is a reactive agent? A reactive agent waits to be asked. A chat assistant, a coding agent you hand a task, a support bot answering a ticket: each does nothing until a person or a system sends it something, and its work ends when it has answered. It may take many steps and call many tools in between, but the trigger is always outside it. ## What is a proactive agent? A proactive agent starts itself. It wakes on a schedule, on an event it subscribes to (a new ticket, a message in a channel, a deadline approaching), or at a time it booked for itself. Then it decides whether there is anything worth doing. - An agent that asks a colleague for an answer and follows up if none arrives by the time it expected one. - An agent that watches a project board and tells the owner when a task stalls. - An agent that notices a meeting has no agenda the day before and drafts one. The hard part is not acting. It is the judgement about **when**: too early is nagging, too late is useless, twice with nothing new is noise, and silence when something mattered is the failure people remember. ## What is a durable agent? Durable describes how an agent runs, not what starts it. A durable agent records its progress at each step, so work that spans hours or days survives a crash, a deploy or a long wait, and resumes where it stopped without repeating an action it already took. Durable execution frameworks such as [Temporal](https://temporal.io) and [DBOS](https://www.dbos.dev) are built for exactly this. ## How do the three fit together? Ask three separate questions of any agent: 1. **What starts it?** A request (reactive) or its own trigger (proactive). 2. **How long does it live?** One request (ephemeral) or across hours and days (durable). 3. **Who approves what it does?** A person signs off each action (assisted), or it acts on its own (autonomous). A coding agent is usually reactive, ephemeral and assisted. A follow-up agent is proactive, durable and often autonomous for small things like a reminder, with a person approving anything bigger. ## Why do proactive agents usually need to be durable? Because proactivity happens over time. An agent that chases a reply has to remember who it asked, what, when, and when it expects an answer, across many wakes that may be a day apart. If that memory lives only in a running process, a restart erases the agent's sense of what it is waiting for. ## How do you test each kind? A reactive agent can be tested the familiar way: give it an input, judge the output. A proactive, durable agent cannot, because its mistakes are about timing and only show up across days and other people's behaviour. Testing it means playing it through simulated time, with simulated colleagues who answer late or never. That is what we built [Minutehand](https://github.com/Alknoma/minutehand) for: it runs an agent through simulated days of work in seconds, against fake Slack, Jira, Notion and other services, and reports every move made too early, too late, twice, or on a fact the agent made up. ## Frequently asked questions ### What is the difference between a reactive and a proactive agent? A reactive agent acts only when someone asks it to: a prompt goes in and an answer comes out. A proactive agent starts itself from an event, a schedule or a signal it is watching, so it also has to decide whether to act at all and when. ### What is a durable agent? A durable agent saves its state at each step, so work that runs for hours or days survives crashes, restarts and long waits, and resumes where it stopped without repeating an action it already took, such as sending the same email twice. ### Can an agent be both proactive and durable? Yes, and most useful proactive agents are. An agent that chases a reply over two days has to remember what it asked, when, and of whom, across many wakes. That memory and the waits between wakes are what durability provides. ### How do you test a proactive, durable agent? Not with a single prompt and its reply. Its mistakes are about timing: acting too early, too late, twice, or not at all. Testing it means playing it through simulated time with simulated people, which is what Alknoma's Minutehand does. --- # How do you build a proactive agent? By Howard Chen (https://www.linkedin.com/in/howard-h-chen/), 9 October 2026. https://www.alknoma.com/blogs/how-to-build-a-proactive-agent **Alknoma, in the proactive agent space, builds proactive AI agents for teams and tests them with Minutehand. A proactive agent needs four parts: a goal, a memory it writes as it works, a way to wake itself, and rules for when to act and when to wait. Minutehand then plays it through simulated days before it reaches real people.** Most agent tutorials build something reactive: a request comes in, the agent works, an answer goes out. A proactive agent turns that around. It starts itself, and most of the time the right thing for it to do is nothing. ## 1. Give it a goal it can finish "Keep the project moving" never ends, so the agent never knows when to stop. "Confirm the offsite venue with Rosa and tell Owen" has an owner, a person to ask, and a done state. Give the goal a deadline too, so the agent knows when to give up and say so. ## 2. Give it a memory that outlives each wake Between wakes the process may restart, so anything the agent needs next time must be written down. For each open item store who was asked, what, when, and when an answer is expected. On the next wake the agent reads its open items first, before it does anything else. ## 3. Give it ways to wake - **Events:** a message in Slack or Teams, a ticket changing state, a webhook from a service it watches. - **Its own bookings:** when it asks someone something, it books a wake for when the answer is due. - **A schedule:** a daily or weekly pass, as a safety net rather than the main trigger. Wakes it books for itself matter most. An agent that only runs on a fixed timetable either checks too often and nags, or too rarely and misses things. ## 4. Write down when to act, and when to wait This is the part people skip and users notice. Make the rules explicit so they can be reviewed and tested: - Do not follow up before the answer is due. - Do not send the same message again with nothing new in it. - When someone answers, come back to it promptly and pass the answer on. - Never state a fact nobody gave you. - At the deadline, stop and tell the owner where things stand. ## 5. Keep a person in the loop where it counts Let the agent act alone on small, reversible things like a reminder, and ask a person before anything that is hard to undo or speaks for them in a new way. The line between the two belongs in the same rules as the timing. ## 6. Test it over time before it reaches people A proactive agent's bugs are timing bugs, and they only show up over days. You cannot find them by sending one prompt and reading one reply. Play the agent through simulated days instead, with simulated colleagues who answer late or never, and check every move against your rules. We built [Minutehand](https://github.com/Alknoma/minutehand) for this step. It runs your agent against fake Slack, Teams, Jira, Asana, Notion, GitHub and Google Drive, owns the clock so days pass in seconds, and flags each follow-up sent too early or too late, each repeat, and each made-up fact, with what it was measured against. ## Frequently asked questions ### What is the difference between a proactive agent and a cron job? A cron job runs the same thing on a fixed timetable. A proactive agent wakes, looks at what has changed since it last woke, and decides whether to act, what to do, and when to wake next. The schedule is only one of its triggers. ### Where should a proactive agent keep its memory? Somewhere that outlives a single run of the process: a database or a durable workflow's state. Store each open item with what was asked, of whom, when, and when an answer is expected, so the next wake can pick up from there. ### How do you stop a proactive agent from being annoying? Write the restraint down as rules: wait until an answer is actually overdue, never send the same message again without something new to say, come back promptly when someone answers, and stop at a deadline. Then test that the agent keeps them. ### How do you test a proactive agent before shipping it? Run it through simulated days against simulated people and services, then check its timing as well as its words. Alknoma's Minutehand does this in seconds and says what each finding was measured against. --- # Your PM Tool Isn't the Problem: What Asana, Jira & monday Don't Solve By Howard Chen (https://www.linkedin.com/in/howard-h-chen/), 22 July 2026. https://www.alknoma.com/blogs/what-asana-doesnt-solve ## What project management tools solve—and what they don't **Your PM tool isn't the problem—but it was never built to solve the one you actually have.** Asana, Jira, and monday are systems of record for the *state* of work: what exists, who owns it, what stage it's in. They're genuinely good at that. What they don't do—what none of them were designed to do—is *move* the work between the people and tools that touch it. The board tells you a task is "In Progress" and blocked on Sam. It doesn't chase Sam, carry the context Sam needs to unblock it, or notice that it's been sitting there four days. The board is updated; the work is still stuck. That gap is the thing teams keep misdiagnosing as a tooling problem. So they migrate—Asana to monday, Jira to Linear—and three months later the same work is stalling in the same seams, just against a nicer background. The tool was never the bottleneck. The coordination *around* the tool was. If your board is tidy and your delivery still feels slow, you're not looking at a feature gap. You're looking at everything that happens in between the columns. ## A board is a map, not an engine A project management tool is a map of your work. Maps are useful—you want one, and a team without one is worse off. But a map doesn't drive. Keeping it accurate is itself work: someone updates the status, drags the card, writes the comment that says what actually happened. And here's the quiet cost of doing that well—the more faithfully your team maintains the board, the more it can *look* like coordination is happening when it isn't. A perfectly groomed backlog and a task that's been silently blocked for a week can coexist happily. The green board hides the red work. This is one of the places the [coordination tax](/blogs/coordination-tax)—the time a team burns keeping work aligned instead of doing it—hides most effectively, because a clean status column reads as progress even when nothing has moved. Everyone's looking at the map and assuming the drive is happening. ## The three things the board doesn't do - **It doesn't chase.** A task marked blocked stays blocked until a human remembers it, opens a chat window, and types "any update on this?" The board records the blocker; it never nudges the person who could clear it. The follow-up is left entirely to whoever happens to notice. - **It doesn't carry context.** When a card moves to the next column, the *what* travels and the *why* gets stripped off. The receiver inherits a task with the reasoning missing and has to reconstruct it—re-reading threads, pinging the sender. The board marks that the [handoff happened](/blogs/context-handoffs-why-work-stalls); it doesn't make the context make the trip. - **It doesn't notice waiting.** A task can sit untouched for a week and the board looks identical on day one and day seven. Silence isn't a state a PM tool acts on—it's just the absence of an update. Work stalls quietly, in a queue no one is actively watching, until someone stumbles on it. None of these are failures of the tool. Asana isn't broken because it doesn't chase Sam—chasing Sam was never in scope. These are the coordination jobs that live *around* the board, in the gaps between the tool and the people and the other tools. And because they don't belong to any single app, they end up belonging to everyone, paid out of attention in five-minute increments no one ever tallies. ## Why migrating tools doesn't fix it When work keeps stalling, a tool migration feels like decisive action. New board, cleaner workflow, a fresh start—and for a few weeks it even helps, because setting it up forces the team to talk about how work should flow. Then the honeymoon ends and the same tasks start going quiet in the same places. The migration reset the map. It didn't touch the seams around it. This is the rebuild loop that turns a coordination problem into [AI workflow debt](/blogs/ai-workflow-debt): rather than fixing the handoffs between tools and people, teams keep swapping the tool at the centre, generating a new island of setup work and a new set of gaps to bridge by hand. The bottleneck was never the interface. It was that nothing owns the movement of work *between* interfaces—and a shinier board doesn't change who owns it (still: nobody). ## "The board is updated; the work is still stuck" Picture the most ordinary version of this. A ticket moves to "Needs review." It's assigned to a reviewer who has forty other notifications, so it sits. Two days later the person who wrote it checks the board, sees "Needs review," and assumes it's handled—the status says so. Another two days pass. Eventually someone in standup asks about it, the reviewer says "oh, I didn't see that," and now a five-minute review has cost most of a week. At no point did the board lie. Every status was accurate. That's the whole point: a PM tool faithfully reported the *state* of the work while the *movement* of the work quietly failed. The tool did its job. The coordination—getting the right task to the right person at the right moment, and noticing when that didn't happen—was the part with no owner. ## What actually closes the gap The fix isn't a better board or a different one. It's a layer that does the jobs the board can't: it carries context across a handoff so the receiver can act without reconstructing the story, routes work to the specific person who now holds it instead of a column everyone assumes someone else is watching, and treats silence as something to follow up on rather than a state to ignore. The map stays a map; something has to be the engine. That engine is what we're building at Alknoma. It doesn't replace Asana or Jira—it sits alongside the tools you already use and keeps the work moving between them: chasing the follow-ups, carrying context to the right owner, and surfacing what's stalled before it costs you a week. If your board is always up to date and your delivery still drags, that gap between "the status is current" and "the work is moving" is exactly the problem we'd love to take off your plate. We only take on a handful of design partners at a time, and we start by owning your worst coordination bottleneck—not by handing you another tool to maintain. If you want the other side of this—why individual speed rarely adds up to team speed—we get into it in [the coordination tax](/blogs/coordination-tax), and if you're weighing an autonomous agent against a layer that connects what you have, we compare the two in [AI coworkers vs coordination layers](/blogs/ai-coworkers-vs-coordination-layers). ## Stop grading the board. Start moving the work. A project management tool answers one question well: what is the state of the work? That's worth having. But it quietly lets you believe that keeping the map accurate is the same as keeping the work moving, and it isn't. The teams that pull ahead aren't the ones with the most disciplined board. They're the ones where the work moves on its own between the columns—where context travels, follow-ups happen without anyone remembering to send them, and nothing sits stalled behind a status that says everything's fine. Your PM tool was never going to do that. It was never supposed to. ## Frequently asked questions ### Is Asana, Jira, or monday the problem if work keeps stalling? Almost never. Those tools are systems of record—they track the state of work accurately and reliably. Work stalls in the coordination around the board: the chasing, the context that doesn't travel with a handoff, the task that sits blocked while no one notices. That's a gap none of them were designed to close, so switching between them rarely helps. ### What don't project management tools solve? They tell you the state of the work but they don't move it. A PM tool can show a task is 'In Progress' and blocked on someone, but it won't chase that person, carry the context they need to act, or flag that the task has been sitting untouched for days. It records that work changed hands; it doesn't make the handoff actually happen. ### Should we switch PM tools if work keeps getting stuck? Usually not. A migration—Asana to monday, Jira to Linear—resets the board but not the seams around it, so the same work stalls in the same places three months later against a nicer interface. Before switching, check whether the bottleneck is the tool itself or the coordination happening around it. It's almost always the latter. ### What's the difference between a PM tool and a coordination layer? A PM tool is a map of your work—it shows what exists, who owns it, and what stage it's in. A coordination layer is closer to an engine: it moves work between people and tools, carries context across handoffs, chases the follow-ups, and surfaces what's stalled. The map tells you where things are; the layer keeps them moving. ### Does adding AI to our project management tool fix this? Only partly. AI inside a PM tool can summarise a project or draft an update, but that still lives inside the board. The chasing, context-sharing, and waiting happen between the board and everything else—email, chat, the actual people—so AI bolted onto the tool speeds up describing the work without moving it. --- # Context Handoffs: Why Work Dies Between People (and How to Stop It) By Howard Chen (https://www.linkedin.com/in/howard-h-chen/), 8 July 2026. https://www.alknoma.com/blogs/context-handoffs-why-work-stalls ## What is a context handoff? **A context handoff is the moment work passes from one person, tool, or stage to the next—and the context needed to act on it has to travel with it.** The designer finishes and hands to engineering. Sales closes and hands to onboarding. An AI agent drafts something and hands it to a human to check. Each of those is a handoff, and each one is a place where the *thing* moves but the *understanding* behind it might not. Here's the part most teams miss: **work rarely dies inside a task. It dies in the handoff.** Inside a task, one person holds all the context in their head—the why, the history, the half-decision they made at 4pm on Tuesday. At the handoff, all of that has to be compressed into a message, a ticket, or a Slack ping, moved across a gap, and rebuilt inside someone else's head. Every one of those steps loses something. When enough is lost, the receiver can't act, so they ask a question, or worse, they don't—and the work goes quiet in a queue nobody is watching. That silence is what a stalled project actually looks like up close. ## Why the handoff is the most fragile point in any workflow A handoff is a translation. The sender knows everything; the receiver knows almost nothing. To close that gap, the sender has to anticipate what the receiver will need, package it, and send it—all while their own attention is already moving on to the next thing. It almost never happens completely. What gets sent is the *what* ("here's the ticket"), and what gets dropped is the *why* ("we chose this because the last approach broke onboarding, and legal already signed off on the wording"). So the receiver inherits a task with the story stripped off. Now they have two choices, and both are expensive. They can reconstruct the missing context themselves—re-reading threads, pinging the sender, hunting through docs—which is pure overhead. Or they can proceed without it and make a decision the sender would have made differently, which creates rework later. Multiply that by every handoff in a workflow and you get the familiar feeling of a team that's individually fast and collectively slow. ## What actually leaks in a handoff - **The 'why'.** The decision travels but its reasoning doesn't. The receiver knows *what* to do and has no idea whether they're allowed to change it, so they either over-ask or over-assume. - **The history.** What was already tried, what got ruled out, who already weighed in. Without it, the receiver re-opens settled questions and re-does dead-end work. - **The ownership.** Handing to a channel isn't handing to a person. When a task lands in a group, everyone assumes someone else has it, and it sits—the diffusion of responsibility that makes shared inboxes go quiet. - **The deadline's meaning.** "By Friday" travels; "by Friday because the client call is Monday and this blocks it" does not. The receiver can't prioritise what they can't see the stakes of. - **The signal that a handoff even happened.** Half the time the sender assumes the receiver saw the message. The receiver never did. The work is now in a gap between two people, owned by neither, discovered days later with an "any update?" None of these are individual failures. They're structural. The handoff is a lossy channel by default, and no amount of "be more communicative" fixes a channel that was never built to carry context in the first place. This is the mechanism underneath the broader [coordination tax](/blogs/coordination-tax)—the time and attention a team burns keeping work aligned instead of doing it. Handoffs are where that tax gets charged most heavily, because they're where context is most expensive to move. ## Why AI made this worse before it made it better The intuitive bet was that AI would smooth handoffs—summarise the thread, draft the ticket, brief the next person. In practice, the first-order effect has been the opposite: **more agents means more seams.** Every AI tool that does part of a job creates a new handoff at its edge, where its output has to be passed to a human or another tool with the context intact. An agent that drafts a reply still has to hand it to someone who knows whether the tone is right for *this* customer. An agent that triages tickets still has to hand the hard ones to a person who needs the reasoning, not just the label. So the count of handoffs goes up, and each new one is a fresh place for context to leak. That's the accumulation we've called [AI workflow debt](/blogs/ai-workflow-debt): a pile of automations that each save time in isolation while quietly multiplying the gaps between them. AI doesn't remove the handoff problem—it relocates and multiplies it, into seams that are even harder to see because a machine, not a person, is on one end. If you've felt that your team runs more tools and moves no faster, this is a large part of why; it's the same pattern behind why [AI workflows break in async teams](/blogs/why-ai-workflows-break-async-teams). ## How to stop work dying in the handoff 1. **Make context travel with the request.** The single highest-leverage move. A handoff should arrive carrying the why, the history, and the stakes—not as a bare task the receiver has to investigate. If the context has to be chased *after* the handoff, the handoff was incomplete. 2. **Hand off to a person, not a channel.** Name the owner. "Can someone look at this?" in a group is not a handoff—it's a hope. Route the work to the specific person who now holds it, so ownership transfers along with the task. 3. **Send the decision, not just the deliverable.** Attach the reasoning: what you chose, what you ruled out, what the receiver is free to change. It costs the sender thirty seconds and saves the receiver an hour of reconstruction. 4. **Make waiting visible.** A handoff that stalls should surface on its own. Treat silence after a handoff as a state to follow up on automatically, not a success to assume. The goal is that nothing sits unnoticed in the gap between two people. 5. **Close the seam AI opens.** Every time you add an agent, ask who receives its output and whether they get the context to act on it. An automation that gets you 80% of the way and drops the last 20% into someone's lap has just created a new handoff, not removed one. ## The handoff should carry its own context The teams that move fast aren't the ones with fewer handoffs—handoffs are how specialised people work together, and you can't design them away. They're the teams where the handoff itself carries its own context, where work arrives ready to be acted on and nothing has to be reconstructed to get started. That's a property of the system connecting people, not of how diligent any one person is on a given afternoon. That's exactly the layer we're building at Alknoma. Instead of leaving every handoff to be packaged by hand and hoping nothing leaks, Alknoma keeps context moving between the people and tools you already use—so the right work reaches the right person with the reasoning attached, and the ones that stall get surfaced instead of forgotten. If the place your work keeps dying is the gap *between* steps rather than inside them, that's the exact problem we'd love to take off your plate. ## Frequently asked questions ### What is a context handoff? A context handoff is the moment a piece of work moves from one person, tool, or stage to the next, and the information needed to act on it—the why, the history, the decision behind it—has to travel along with it. A clean handoff carries its own context so the receiver can act immediately. A lossy one arrives as a task with the story stripped off, and the receiver has to reconstruct it before anything happens. ### Why does work stall between people rather than within a task? Because the work itself usually isn't the hard part—the transfer is. Inside a task, one person holds all the context. At the handoff, that context has to be packaged, moved, and rebuilt in someone else's head, and every step of that is where detail leaks, ownership blurs, and the item goes quiet in a queue nobody is watching. ### How do you fix broken context handoffs? Make context travel with the request instead of being chased after it. Hand off to a specific owner, not a channel. Include the decision and the 'why', not just the 'what'. And make waiting visible so a stalled handoff surfaces on its own instead of being discovered days later when someone asks 'any update?' ### Isn't this what project management tools already do? PM tools track that a handoff happened—the card moved to the next column. They rarely carry the context across it. The board tells you work changed hands; it doesn't tell the receiver why the decision was made, what was already tried, or that they're now the one holding it. The status is updated and the work is still stuck. ### Does AI reduce handoff problems? Not on its own—it usually adds more handoffs. Every AI agent that does part of a job creates a new seam where its output has to be handed to a person or another tool, with context intact. Unless something owns those seams, AI multiplies the number of places work can die between steps rather than reducing them. --- # How to Reduce Coordination Overhead in Remote Teams (Without More Meetings) By Howard Chen (https://www.linkedin.com/in/howard-h-chen/), 1 July 2026. https://www.alknoma.com/blogs/reduce-coordination-overhead-remote-teams ## How do you reduce coordination overhead in remote teams? **You reduce coordination overhead in a remote team by removing the reasons people have to interrupt each other—not by scheduling another meeting to sync.** Most overhead is the cost of information not being where it needs to be: context that has to be chased, decisions that have to be tracked down, updates that have to be requested. Fix those at the source and the need for real-time coordination shrinks on its own. Concretely, that's four moves. Make context travel with the work so nobody re-asks. Route each decision to the person who owns it instead of broadcasting it to a channel. Make waiting visible so stalled work gets a nudge automatically. And automate the routine chasing entirely. None of them require a call. All of them attack the thing meetings only paper over. The rest of this post is how each one works—and why the reflex to "just add a standup" quietly makes remote teams slower. ## What coordination overhead actually is Coordination overhead is the share of your week spent keeping work aligned rather than doing it. The "any update?" ping. The half-hour hunting for a doc that already exists. The status meeting whose only purpose is to tell everyone what everyone else is doing. The message you send three times before someone replies. None of it is the work. All of it is the cost of doing the work *together*—and it's spread across everyone's day in five-minute increments, which is exactly why it hides in plain sight and nobody owns reducing it. This is what we call the [coordination tax](/blogs/coordination-tax), and remote teams pay a heavier rate. Not because remote workers are less disciplined—because remote removes the ambient, accidental coordination that co-located teams never had to think about. In an office, half of this got settled by overhearing a conversation or catching someone at their desk. Remove the room and every one of those exchanges has to become a deliberate, explicit act. The overhead didn't appear when you went remote. It just stopped being invisible. ## Why the default fix makes it worse When a remote team feels out of sync, the instinct is to add a meeting. A daily standup. A weekly sync. A "quick call to align." It feels productive because for thirty minutes everyone is, in fact, aligned. But a meeting is a synchronous patch on an asynchronous problem. It forces the whole team online at the same moment to exchange information that could have moved on its own—and it charges that cost to every calendar, every day, whether or not there was anything to say. It's also a false economy. The information shared in a standup was available before the standup and will be stale after it. What you've actually built is a recurring tax that everyone pays to compensate for context that doesn't travel. The teams that feel fastest aren't the ones with the most syncs. They're the ones that need the fewest, because the coordination happens without a meeting having to host it. ## Four ways to reduce it—without a single new meeting 1. **Make context travel with the work.** Most re-asking happens because context can't move—it's stuck in one person's head or a thread nobody else saw. When the relevant background arrives *with* the request, nobody has to reconstruct the story before they can act. This is the single highest-leverage change, because it kills the two biggest line items at once: the chasing and the context-hunting. 2. **Route decisions to the owner, not the room.** Broadcasting a question to a channel of twelve people is how you get zero answers and a diffusion of responsibility. Send it to the one person who actually owns the decision, with enough context to answer in a sentence, and it gets answered in a sentence. Directed beats broadcast every time in a remote team. 3. **Make waiting visible.** In async work, the most expensive state is silence—work sitting idle in a queue no one is watching. Treat a stalled item as a thing to follow up on, not a success. If your system can't tell you what's waiting on whom, it will let work die quietly between people, and you'll only find out at the next meeting. 4. **Automate the chasing.** The follow-ups, the status-nudges, the "circling back on this"—it's routine, rules-based, and it shouldn't need a human at all. Chasing is not a leadership skill; it's a symptom of coordination that isn't automated. The moment a machine handles the nudging, you get the alignment a standup was buying you, without the standup. None of these four is a tool you install. They're properties a team either has or doesn't. And they're exactly the habits that AI depends on, too—drop automation onto a team without them and it breaks in predictable ways, which we've written about in [why AI workflows break in async teams](/blogs/why-ai-workflows-break-async-teams). Weak coordination doesn't get fixed by AI. It gets amplified by it. ## Measure it before you try to fix it You can't shrink what you haven't named. For one week, have the team track the time that isn't the work: messages sent purely to nudge or ask for status, hours in status and sync meetings, minutes spent searching for context that already exists somewhere, and work sitting idle waiting on a reply or approval. Add it up. The number is almost always larger than anyone guessed—and once it's on the table, reducing it stops being a vague aspiration and becomes a target with a baseline. Watch the waiting number in particular. Chasing and meetings are visible; waiting is the silent one, because idle work doesn't generate any activity to notice. It's frequently the biggest single cost and the one no dashboard shows you. If you fix one thing this quarter, make it the queue nobody is watching. ## Coordination should be infrastructure, not everyone's side job Here's the shift that actually moves the needle: stop treating coordination as a personal responsibility every teammate carries out of their own attention, and start treating it as something the system handles. Context that moves on its own. Decisions that reach the right person. Follow-ups that happen without anyone remembering to send them. When coordination is infrastructure, the overhead doesn't get redistributed—it gets removed. That's exactly what we're building at Alknoma: a coordination layer that carries context, routes work to the right person, and automates the chasing and follow-ups—so the work reaches the right person at the right time without a meeting having to make it happen. If your remote team feels slower than its size should allow, the overhead is usually where the time went, and it's the problem we'd love to take off your plate. And if you've noticed that adding AI tools hasn't shrunk the overhead the way you hoped, there's a reason for that: unfinished, disconnected automations quietly accumulate their own drag. We call it [AI workflow debt](/blogs/ai-workflow-debt)—and it's the next thing worth reading if this one hit home. ## Frequently asked questions ### How do you reduce coordination overhead in remote teams? Remove the reasons people have to interrupt each other, rather than scheduling more syncs. In practice that's four moves: make context travel with the work so nobody re-asks, route each decision to the person who owns it instead of broadcasting, make waiting visible so stalled work gets nudged, and automate the routine chasing. None of them require a meeting. ### Why don't more meetings reduce coordination overhead? Because meetings are the overhead. A standup is a synchronous fix for an asynchronous problem: it forces everyone online at once to exchange information that could have travelled on its own. It can mask the symptom for a day, but it adds fixed cost to every calendar and it doesn't fix the reason the information wasn't already where it needed to be. ### What causes coordination overhead in remote teams? Distributed context and time zones. When context lives in someone's head, an inbox, or a thread nobody else saw, every handoff turns into a chase. And because coordination scales with the number of connections between people—not the number of people—overhead grows faster than the team does. Remote just removes the hallway that used to hide it. ### How do you measure coordination overhead? For one week, count the time that isn't the work: messages sent purely to nudge or ask for status, hours in status and sync meetings, time spent searching for context that already exists, and work sitting idle waiting on a reply or approval. Most teams are surprised how much of the week that adds up to—and naming the number is what makes reducing it a priority. ### Can AI reduce coordination overhead? Only if it automates the coordination itself, not just individual tasks. Most AI speeds up the work a person does and leaves the chasing, context-hunting, and follow-ups untouched—or relocates them into the seams between tools. AI reduces overhead when it runs the routine coordination layer: carrying context, routing decisions, and following up on silence. --- # The Coordination Tax: Why Teams Lose More to Talking About Work Than Doing It By Howard Chen (https://www.linkedin.com/in/howard-h-chen/), 30 June 2026. https://www.alknoma.com/blogs/coordination-tax ## What is the coordination tax? **The coordination tax is the time and attention a team spends keeping work aligned instead of doing the work itself.** It's the "any update?" pings, the status meeting that exists to sync everyone, the half-hour spent hunting for a doc that already exists, the message you send three times before someone replies. None of it is the work. All of it is the cost of doing the work *together*. Every team pays it. Most never measure it. And because it's spread across everyone's day in five-minute increments, it hides in plain sight—it never shows up as a line item, so no one owns reducing it. It hides especially well inside a tidy project board, which is [exactly what your PM tool doesn't solve](/blogs/what-asana-doesnt-solve): the status is current while the work behind it sits stuck. ## Why it scales faster than headcount Here's the uncomfortable math. Work doesn't scale with the number of people; coordination scales with the number of *connections between* them. Add a tenth person to a team of nine and you haven't added one more relationship—you've added nine. The communication paths grow roughly with the square of team size. So a team that doubles in size doesn't double its coordination overhead. It more than quadruples the ways information has to travel, the hand-offs that can drop, and the people who need to be kept in the loop. This is why teams often feel *slower* right after they grow: the new capacity gets eaten by the new coordination tax before it ever reaches the work. ## Where the tax actually gets paid - **Chasing.** Messages whose only purpose is to nudge work forward—"any update?", "did you see this?", "still waiting on X." - **Context-hunting.** Re-reading threads, digging through docs, and re-asking for information that already exists somewhere. - **Status syncs.** Meetings that exist mostly so everyone can find out what everyone else is doing. - **Hand-off friction.** The work is 80% done by a tool or a teammate, and someone spends real time stitching the last 20% across the gap—the [context handoff](/blogs/context-handoffs-why-work-stalls) is where work most often stalls. - **Waiting.** Approvals, reviews, time zones—work sitting idle in a queue no one is actively watching. ## Why AI hasn't fixed it (yet) The hope was that AI would absorb this overhead. Mostly, it has *relocated* it. Individual tasks get faster, but the coordination work doesn't disappear—it moves into the seams between your tools, where it's even harder to see. We've written about how this accumulates as [AI workflow debt](/blogs/ai-workflow-debt), and why AI speed-ups so often fail to show up at the team level in [how much time AI really saves](/blogs/ai-productivity-truth-time-savings). The pattern is consistent: **AI makes individuals faster, but teams still move at the speed of their coordination.** Until the coordination layer itself is automated, the tax stays on the books. ## How to shrink the coordination tax 1. **Measure it first.** For one week, count the time that isn't the work: status meetings, nudge messages, context searches, idle waiting. Naming the number is what makes it a priority. 2. **Make context travel with the request.** When the background arrives with the ask, no one has to reconstruct the story before they can act—most re-asking simply disappears. 3. **Route to the owner, not the room.** Decisions should reach whoever actually owns them, with enough context to answer quickly, instead of being broadcast to everyone. 4. **Make waiting visible.** Treat silence as a state to follow up on, not a success. Work shouldn't stall quietly in an inbox. 5. **Automate the chasing.** The follow-ups and status-nudging are routine and rules-based—exactly the kind of coordination that shouldn't need a human at all. ## Coordination should be infrastructure, not everyone's side job Right now, coordination is a tax every person on the team pays out of their own attention. It doesn't have to be. The teams that pull ahead treat coordination as something the system handles—context that moves on its own, decisions that reach the right person, follow-ups that happen without anyone remembering to send them. That's exactly what we're building at Alknoma: a coordination layer that automates how teams communicate and align, so the tax shrinks and the work gets the attention instead. If your team feels slower than its size should allow, the coordination tax is usually where the time went—and it's the problem we'd love to take off your plate. Deciding between an autonomous agent and a coordination layer? We compare the two approaches in [AI coworkers vs coordination layers](/blogs/ai-coworkers-vs-coordination-layers). ## Frequently asked questions ### What is the coordination tax? The coordination tax is the share of a team's time and attention spent keeping work aligned rather than doing the work itself: chasing updates, hunting for context, status meetings, hand-offs, and waiting on replies. It's the overhead of working together, and it's paid by everyone, every day. ### Why does the coordination tax grow as teams scale? Because communication paths grow faster than headcount. Add people and the number of connections between them rises roughly with the square of team size, so every new hire adds more coordination than the last. A team twice the size doesn't have twice the overhead—it has far more. ### Hasn't AI reduced the coordination tax? Not yet—mostly it relocates it. AI speeds up individual tasks, but the chasing, context-hunting, and follow-ups move into the seams between tools, where they're harder to see. Unless the coordination layer itself is automated, individual speed-ups get absorbed by overhead. ### How do you measure the coordination tax? Track where time goes that isn't the work: hours in status/update meetings, messages sent purely to nudge or ask for status, time spent searching for context that already exists, and idle time waiting on a reply or approval. Most teams are surprised how much of the week this adds up to. ### How can a team reduce the coordination tax? Make context travel with the request instead of being chased, route decisions to the specific owner rather than broadcasting, make waiting visible so nothing stalls silently, and automate the routine chasing and follow-ups. The goal is to spend less attention on aligning work and more on doing it. --- # AI Workflow Debt: The Hidden Tax Slowing Your Team Down By Howard Chen (https://www.linkedin.com/in/howard-h-chen/), 30 June 2026. https://www.alknoma.com/blogs/ai-workflow-debt ## What is AI workflow debt? **AI workflow debt is the accumulated cost of AI automations that were never finished, never connected, or never maintained.** Every quick win—an agent wired into one channel, a prompt chain that works for one person, a script that bridges two tools—adds a little drag. Individually they save time. Collectively, they form a tangle that someone has to remember, babysit, and route around. That tangle is the debt. The phrase borrows from *technical debt*, and the analogy holds. Technical debt is the future cost of shipping code the fast way instead of the right way. AI workflow debt is the future cost of automating the fast way instead of the coordinated way. In both cases the interest is paid in time, attention, and trust—and it compounds. ## Why it accumulates faster than you think Three things make AI workflow debt accrue quietly. First, the wins are visible and the costs are invisible. The demo that saves an afternoon gets celebrated; the six follow-ups a week needed to keep it running never land on anyone's roadmap. Second, the debt is distributed. No single automation is the problem—it's the seams between them, which is exactly where no one owns the work. Third, AI lowers the cost of *starting* an automation to nearly zero, so teams start far more of them than they finish. The result is a familiar pattern: lots of AI in use, very little measurable improvement. Research from the [Stanford Institute for Human-Centered AI](https://hai.stanford.edu/ai-index/2025-ai-index-report) keeps finding the same gap—AI is embedded everywhere in day-to-day work, yet team-level outcomes stay uneven. The models aren't the bottleneck. The unfinished plumbing between them is. ## What AI workflow debt looks like in practice - **Orphaned automations.** A bot that summarises a channel nobody reads anymore, still running because no one's sure what breaks if it stops. - **Prompt chains with a single owner.** They work beautifully until that person is on leave—then the whole flow stalls and nobody can explain it. - **Tool-to-tool gaps filled by people.** The automation gets you 80% of the way; a human copies, pastes, and reformats the last 20% every single time. - **Re-asking instead of retrieving.** The answer exists in a thread, a doc, and an agent's output—so people re-ask rather than hunt, and the AI happily generates a fresh, slightly different answer. - **Silent failures.** An automation quietly stops firing and the work it covered disappears into a queue no one is watching. If those feel familiar, you're not looking at an AI capability problem. You're looking at a coordination problem wearing an AI costume. We've written before about how [AI workflows break in async teams](/blogs/why-ai-workflows-break-async-teams)—workflow debt is what that breakage leaves behind once the demos are over. ## The compounding cost: sunk cost meets rebuild loop Workflow debt gets expensive through two reinforcing traps. The first is the **sunk-cost trap**: a team has invested so much in a brittle setup that abandoning it feels like waste, so they keep patching it. The second is the **rebuild loop**: rather than fix the seams, someone rebuilds the automation from scratch—creating a new island of value and a new set of seams to maintain. We unpack both in [The Real Cost of AI: Sunk Costs, Rebuilds, and Workflow Debt](/blogs/ai-sunk-costs-rebuilds-workflow-debt). The throughline is simple. **AI doesn't reduce coordination work—it relocates it.** The chasing, the context-hunting, and the follow-ups don't disappear; they move to the gaps between your tools, where they're harder to see and easier to ignore. ## How to pay it down 1. **Make the debt visible.** Inventory your live automations and ask three questions of each: who owns it, what breaks if it stops, and how you'd know if it failed silently. Anything that fails all three is interest you're paying blind. 2. **Fix seams, not features.** The leverage is in the handoffs between tools and people, not in a smarter prompt. Close the gap a human is manually bridging before you add another automation. 3. **Give context a place to live.** Most re-asking happens because context can't travel. When the right background arrives with the request, the AI—and the person—can act without reconstructing the story first. 4. **Make waiting visible.** Treat silence as a state to follow up on, not a success. An automation that stalls quietly is worse than one that fails loudly. 5. **Stop starting; start finishing.** Set a cap on in-flight automations. A finished, owned, monitored workflow beats three clever half-built ones every time. ## Coordination is the asset, not the automation The teams that get real leverage from AI aren't the ones with the most automations. They're the ones whose automations connect—where context moves to the right person at the right moment and nothing stalls in a queue no one is watching. That's the difference between a pile of clever scripts and an actual coordination layer. That coordination layer is exactly what we're building at Alknoma. Instead of adding another island of automation, Alknoma keeps communication moving across the ones you already have—so the work AI starts actually finishes. If your team is feeling the drag of workflow debt, that's the problem we'd love to take off your plate. For the measurement side of this — why the time AI saves so often fails to show up at the team level — see [how much time AI really saves](/blogs/ai-productivity-truth-time-savings). This is one face of a bigger problem: the [coordination tax](/blogs/coordination-tax) every team pays in chasing, context-hunting, and waiting. ## Frequently asked questions ### What is AI workflow debt? AI workflow debt is the accumulated cost of AI automations that were never finished, never connected, or never maintained. Each quick win adds a little drag, and the tangle of half-built flows someone has to babysit and route around becomes the debt. Like technical debt, it compounds—paid in time, attention, and trust. ### What causes AI workflow debt? Three things: the wins are visible while the maintenance costs are invisible; the debt is distributed across the seams between tools, which no one owns; and AI makes starting an automation nearly free, so teams start far more flows than they finish. ### How is AI workflow debt different from technical debt? Technical debt is the future cost of shipping code the fast way instead of the right way. AI workflow debt is the future cost of automating the fast way instead of the coordinated way. Both compound, but workflow debt lives in the handoffs between AI tools and people rather than in a codebase. ### How do you reduce AI workflow debt? Make the debt visible by inventorying live automations (who owns it, what breaks if it stops, how you'd know it failed). Fix the seams between tools instead of adding features, give context a place to live so people stop re-asking, make waiting visible, and cap the number of in-flight automations so flows actually get finished. ### Does AI reduce coordination work? No—AI relocates coordination work rather than removing it. The chasing, context-hunting, and follow-ups move into the gaps between your tools, where they are harder to see and easier to ignore. Teams that win with AI connect their automations into a coordination layer instead of accumulating isolated ones. --- # AI Coworkers vs Coordination Layers: Two Very Different Bets on Team AI By Howard Chen (https://www.linkedin.com/in/howard-h-chen/), 30 June 2026. https://www.alknoma.com/blogs/ai-coworkers-vs-coordination-layers Almost every AI-for-teams product on the market today is quietly making one of two bets. Understanding which bet a tool is making—and which one *your* team actually needs—matters more than any feature list. ## Bet #1: The AI coworker The first bet is the **AI coworker** (sometimes "AI employee" or "AI agent"). The idea: give the team an autonomous agent that does work like an extra headcount. It lives in Slack or Microsoft Teams, takes a task, and executes it—writing, running code, pulling reports, operating across your other tools. Products like **Viktor** are clear examples of this category: an AI coworker that proactively executes tasks across thousands of integrations. It's a compelling bet, and for the right problem it's powerful. If your constraint is *throughput*—too much work, not enough hands—an agent that autonomously does tasks adds real capacity. ## Bet #2: The coordination layer The second bet is the **coordination layer**. Instead of adding a worker, it automates *how work moves between the workers you already have*. It carries context with each request, routes decisions to the person who actually owns them, makes waiting visible, and handles the routine chasing and follow-ups—so work doesn't stall in the gaps between people and tools. This is the bet Alknoma makes with Ayven. The premise: for most teams, the bottleneck was never how fast individuals do tasks. It's the [coordination tax](/blogs/coordination-tax)—the hours lost to chasing updates, hunting for context, and waiting on replies. AI that does tasks faster doesn't fix that; it often just [relocates the coordination work into the seams](/blogs/ai-workflow-debt). ## They solve different problems This isn't a "which is better" question—they target different constraints: - **AI coworker** — best when the constraint is *execution capacity*. You need more work done and want an agent to autonomously do it. - **Coordination layer** — best when the constraint is *the seams*. Your people are capable, but work keeps stalling between them: missing context, unclear ownership, silent waiting. A useful test: if you cloned your best person five times, would the work move dramatically faster? If yes, you have a throughput problem—an AI coworker helps. If the clones would still be stuck waiting on each other, re-asking for context, and chasing updates, you have a coordination problem—and more execution capacity won't fix it. ## Why the distinction is about to matter more As teams adopt more AI coworkers and agents, a second-order problem appears: all that autonomous output still has to be routed, reviewed, and handed off between people. More agents can mean *more* coordination, not less. That's why the two bets are ultimately complementary—the coordination layer is what stops a growing pile of AI tools from collapsing into [AI workflow debt](/blogs/ai-workflow-debt). So the honest answer to "AI coworker or coordination layer?" is: figure out whether your team's real bottleneck is *doing* the work or *moving* it. If it's the moving—the chasing, the context, the waiting—that's the problem Alknoma is built to take off your plate. ## Frequently asked questions ### What's the difference between an AI coworker and a coordination layer? An AI coworker is an autonomous agent that does tasks like an extra team member—it writes, runs code, and executes work on its own. A coordination layer doesn't do the work; it automates how work moves between the people and tools you already have: carrying context, routing decisions, and chasing follow-ups so nothing stalls between hand-offs. ### Which does my team need—an AI coworker or a coordination layer? If your bottleneck is doing more work with fewer people, an AI coworker that executes tasks helps. If your bottleneck is that work keeps getting stuck between people—chasing updates, hunting for context, waiting on replies—then a coordination layer addresses the actual constraint. Many teams discover their problem was never throughput; it was coordination. ### Is a coordination layer just another AI agent in Slack? No. An AI coworker (like Viktor and similar 'AI employee' products) lives in your chat and autonomously executes tasks. A coordination layer like Alknoma's Ayven sits underneath the team's communication—its job is to keep work moving between people, not to be another worker in the channel. ### Can you use both? Yes. They're complementary. AI coworkers add execution capacity; a coordination layer makes sure the work those agents and people produce actually reaches the right person and doesn't stall in the seams. The coordination layer is what keeps a growing stack of AI tools from turning into workflow debt. --- # The Gap Between Individual AI Gains and Team Performance By Howard Chen (https://www.linkedin.com/in/howard-h-chen/), 2 April 2026. https://www.alknoma.com/blogs/gap-between-individual-ai-gains-and-team-performance A lot of teams implement AI, feel like they're moving faster for a week, and then wonder why nothing critical seems to be moving. The drafts are faster. The summaries are instant. The first pass gets done in half the time. But the launch still stalls. The handoff still breaks. The same questions keep showing up in Slack. Someone still has to chase approvals, explain context again, and work out who actually owns the next step. That's what this article is about. AI can make one person faster very quickly. It does not automatically make the team move faster. That gap is starting to show up in the broader research too. A Microsoft report found that AI is delivering real productivity gains, but that speed alone is not enough; companies must rethink the workflow itself, not just add AI on top of existing work. In small SaaS teams especially, the bottleneck usually isn't the writing. It's the coordination around the work. ### Key Takeaways - Individual AI wins do not automatically translate into team performance. - As teams grow, coordination drag becomes the real bottleneck. - Faster output often creates more loose ends if ownership, context, and approvals are still messy. - Most productivity tools speed up tasks but leave the handoffs untouched. - Stable workflows reduce follow-ups, context chasing, and rework. - The real unlock is not more AI in more tools. It is dependable execution across the team. ## AI can speed up one person. It doesn't automatically speed up the team. Most AI tools are sold through individual demos. One person makes a suggestion. One artifact is generated. Everyone nods. This looks like productivity. But team performance isn't the same as personal speed. If one person can now produce work twice as fast, but the next step still depends on missing context, a delayed approval, or an unclear handoff, the team doesn't move faster. It just accumulates work faster. ![Diagram illustrating the disconnect between individual AI speed and team throughput](https://www.alknoma.com/res/img/blog/blog-12-1.png) If an SDR drafts 50 personalised emails in an hour but the CRM routing breaks halfway through the sequence, that isn't throughput. It's a faster way to create operational mess. The distinction matters because leadership often buys tools based on individual demos. A founder sees a marketing manager summarise a call transcript in real time and assumes the go-to-motion engine is now optimised. It isn't. The summary sits in a Slack channel. The engineer doesn't see it. The product owner doesn't know the priority. The work lands in a void. Individual AI improves task speed. Team performance improves when that speed is absorbed by stable operating workflows. Research points to model capability being high, but integration reliability varies. This variance is where team performance dies. You don't need smarter prompts. You need tighter handoffs. The goal is not to make one person faster. It's to make the chain of work more reliable. When one link speeds up and the next link stays slow, inventory builds up. In knowledge work, inventory is unfinished tickets, unacknowledged messages, and ambiguous requirements. This is why individual AI productivity vs team performance remains skewed in most growth-stage organisations. ## Coordination drag is what actually slows teams down As SaaS teams grow, the work between the work starts to dominate. Not the headline tasks. The invisible ones. The follow-ups. The re-summaries. The "quick clarifications." The status pings. The handoffs that should have been clean but weren't. This is coordination drag. It's the hidden work that makes teams feel busy while actual delivery slows down. The missing layer isn't more prompts or more tools. It's workflow stability: clear ownership, captured context, and reliable handoffs that keep work moving without constant chasing. This gets misdiagnosed as a people problem all the time. It usually isn't. The team isn't slow. The workflow is noisy. Slack is full of this fake work: chasing, clarifying, nudging, summarising, re-triaging. Add AI into that environment without fixing the workflow and you don't remove the noise. You speed it up. Faster output just creates more fragments to reconcile unless someone has already solved ownership, timing, and context. That's why AI doesn't really remove the coordination cost. It just moves it. Instead of waiting for someone to write the update, you wait for someone to verify the AI update because the context got lost somewhere between tools. The bottleneck isn't usually technical. It's operational. It's the gap between generation and execution. Until that gap is fixed, you're not automating the workflow. You're automating confusion. ## A fast AI workflow can still quietly break revenue work Take a simple example. A product manager uses AI to turn customer call notes into CRM updates and follow-up tasks in minutes instead of hours. On paper, that looks like a win. The PM is faster. The notes are richer. The tasks appear instantly. Then a CRM field name changes. Routing breaks. Nobody notices. Nobody clearly owns the workflow. For two weeks, follow-ups never reach the right queue. The PM got faster. The team didn't. Revenue work stalled quietly because nothing in the workflow was checking for drift, preserving context, or escalating failure when something broke. This is what makes these failures so expensive. The speed gain is real. The breakdown is just delayed. Engineering ends up rebuilding the integration because the schema changed. Sales manually reassigns tasks because the owner field is empty. The PM apologises because the notification never fired and the handoff never happened. The AI did its part. The team still paid for the failure. ## The difference between automation and stability Most AI tools optimise for output. Ayven is built around a different assumption: output is not the hard part. Keeping work moving is. That means fewer dropped handoffs, fewer follow-ups, less context chasing, and less work stalling because the wrong person was offline at the wrong moment. **The point is not "more AI." It's dependable help that still works when the workflow gets messy.** That's where governance becomes operational, not theoretical. A report by OneTrust found that 75% of respondents said AI exposed the limitations of legacy governance processes, and 73% said it revealed gaps in visibility, collaboration, and policy enforcement. That doesn't mean every team needs a new layer tomorrow. It does mean that if ownership is fuzzy, handoffs are weak, and timing is implicit, adding more tools is unlikely to fix much. This is the difference between automation and stability. Automation moves data. Stability makes sure it lands in the right place, at the right time, with the right owner. Automation can trigger a workflow. Stability makes sure the workflow actually survives contact with reality. That's the layer most teams are missing. It's what stops the endless questions: Who owns this? Can you resend that? Why didn't this move? Are we still waiting on approval? A stable workflow turns scattered context into accountable action. It knows when something can move, when it should wait, and when a human needs to step in. That's the real difference between a script that runs and a process that delivers. And in a distributed team, that difference matters more than speed. A slow reliable flow beats a fast broken one every time. ## What teams can do now You do not need a six-month transformation programme to improve this. Start by fixing the parts of the workflow that leak the most momentum. - **Map ownership clearly.** Every automated task needs a named owner for the next step. - **Define failure states.** Decide what happens when routing breaks, data drifts, or approvals do not arrive. - **Capture context once.** Put the decision and the reason somewhere durable. - **Set timing rules.** If someone is offline, the workflow should escalate instead of waiting forever. - **Review handoffs.** Look at the last ten automated handoffs. Where did they stall, bounce, or need manual cleanup? These steps are about reducing coordination drag, not producing more activity. You're not trying to generate more tickets. You're trying to close more loops. That's the difference. The goal isn't to make one person look faster. It's to make the work keep moving across the team. ## What a stability layer does not solve A stability layer is not magic. It adds checks. It adds verification. Sometimes it adds latency. That's the trade-off. You cannot remove all friction without increasing risk. And if you add too many gates, you kill the benefit. It also doesn't solve the wrong problems. - It won't fix a bad product strategy. - It won't repair a team that doesn't trust the workflow. - It won't replace judgment. - And it won't save a process that nobody actually follows. If the team keeps bypassing the system, the workflow is not stable. It is optional. That part still has to be earned. Ayven can help make execution more reliable. It cannot supply the intent, the trust, or the decision-making for you. Humans still have to define the logic. Humans still have to decide where risk is acceptable. Humans still have to step in when the stakes are high. That isn't a flaw. It's the point. Stability costs time. Chaos costs more. ## Moving from local wins to team momentum Designing for reliability instead of raw speed is how local AI wins turn into team momentum. If AI has made parts of your team faster but delivery still feels stuck, the missing layer is probably not another tool. It is workflow stability. Start with the handoffs. That is usually where the drag is hiding. AI can make one person faster. Team performance improves when the workflow stops leaking momentum. That is the layer we are building at Alknoma. --- # Busy Isn't Productive: The Hidden Work Slowing Your Team Down By Howard Chen (https://www.linkedin.com/in/howard-h-chen/), 11 March 2026. https://www.alknoma.com/blogs/busy-isnt-productive-hidden-work-slowing-team You've seen this play out before. A sprint starts with clear goals, but by midweek Slack is a blur of @here pings, "just checking in" DMs, and threads that somehow turn into three separate documents. Someone drafts a spec, but approval stalls because the reviewer's in a different time zone. By Friday, the team's exhausted, but the outcomes are... underwhelming. The problem isn't effort. It's the coordination tax: the invisible work created purely to align people, re-explain decisions, and chase missing pieces. This isn't execution. It's fake work, and it quietly eats the capacity teams think they have. ### Key Takeaways - **The real enemy isn't effort, it's coordination drag:** Follow-ups, nudges, and re-summaries quietly consume up to 30% of knowledge-worker time, creating the illusion of progress without moving outcomes forward. - **Slack amplifies urgency, not throughput:** Instant visibility and fast replies increase perceived busyness, but they don't reliably increase measurable output. - **Individual AI wins don't fix team friction:** Faster drafting or triage doesn't fix handoff gaps, timing delays, or unclear ownership; the friction that actually stalls progress. - **Stability beats speed in real workflows:** Teams with clear context capture, ownership rules, and timing discipline move significantly faster than teams optimising only for task velocity. - **What you measure shapes what moves:** Track follow-ups per decision, time to actionable answers, and work stuck "waiting on..." to expose hidden friction. ## Where the coordination tax shows up (the familiar patterns) - **The follow-up spiral:** "Any update?" "Can you review by EOD?" "Just circling back..." - **The re-summary loop:** thread → doc → meeting → DM "just to clarify" - **Approval stalls:** work sits waiting because someone's offline, in meetings, or missed the request - **Re-triage and rework:** tasks bounce because context or ownership wasn't clear ## Why Slack amplifies urgency but not progress Slack (and tools like it) are built for speed: instant visibility, fast replies, and constant motion. The problem is that motion isn't output. A team can respond to 100 pings a day and still ship nothing meaningful. It's the difference between activity and throughput. The "infinite workday" problem isn't that people don't work hard. It's that constant urgency signals keep teams reactive. Here's what actually happens: - **Urgency isn't importance:** A @here ping feels like a fire. Half the time it's a minor clarification that drags three people into a thread. Meanwhile the real work gets pushed down the stack. - **Visibility isn't accountability:** Everyone saw the message. Nobody owned the next step. It gets read, reacts get added, and it quietly becomes "someone should..." - **Fast replies aren't progress:** "I'll take a look" is not a completed handoff. It's just a promise that creates another follow-up later. The result is predictable; teams feel busy all day, but outcomes take longer to materialise. The coordination tax isn't just a time sink, it's a throughput killer. Slack is great at making everyone feel involved. It's less great at shipping outcomes. ## How individual AI wins don't fix team-level friction AI tools promise to save time: faster drafting, smarter triage, automated summaries. And they do, at the level of a single person. But teams don't stall because one person writes slowly. They stall because work gets stuck in the gaps: missing context, unclear ownership, waiting on approvals, and decisions that happen out of order. So even if an agent drafts a spec in minutes or triages leads in seconds, the time saved gets eaten by the same old friction: - **Missing context.** The agent drafts the spec. Review starts. Someone flags a dependency from last quarter that lives in a different doc. Now you're back to context-hunting. - **Unclear ownership.** The agent qualifies a lead. Sales and marketing disagree on the next step. The lead gets re-triaged and the handoff stalls. - **Timing gaps.** The agent summarises the meeting perfectly. The one person who needs to approve it is offline. Work sits in limbo until someone nudges them. - **Approval bottlenecks.** The agent flags a blocker. The human-in-the-loop is swamped. Follow-ups pile up. The "automation" quietly becomes more work to manage. AI can shave minutes off tasks. But if handoffs, ownership, and waiting states don't change, team-level friction doesn't either. The problem isn't the agent's output. It's the workflow gaps around it. This is why teams can feel more productive after adopting AI: faster drafts, quicker summaries, while the real outcomes barely move. AI speeds up tasks. If the workflow stays fragile, the gains don't compound. ## What stable workflows look like in practice Stable workflows don't eliminate coordination. They reduce the tax by making handoffs predictable, context retrievable, and ownership obvious, even when people are offline and priorities change. **Five stability levers that actually work:** 1. **Context capture (stop making people hunt)** — Rule of thumb: if someone asks "where was that decided?" more than once, your workflow is leaking context. 2. **Ownership at handoff (the next step isn't optional)** — Rule of thumb: every handoff should answer: who owns the next step right now? 3. **Timing rules (waiting is a state, not a surprise)** — Rule of thumb: if work is "waiting on someone," the team should know when it will move and what happens if it doesn't. 4. **Approvals with structure (governance without stalls)** — Rule of thumb: approvals should prevent expensive mistakes, not create a second job. 5. **Visibility that reduces noise (so people stop chasing)** — Rule of thumb: if "any update?" is recurring, visibility isn't working. ## How to measure the coordination tax (and reduce it) You can't fix what you can't see. Coordination tax hides in plain sight because it looks like work: follow-ups, clarifications, re-summaries, re-triage, and "quick pings" that multiply. If you want to reduce it, start by measuring the parts of your workflow that quietly stall. Here's a simple coordination tax audit you can run without turning it into a science project. ### What to track (5 signals) ![Tracking the Coordination Tax infographic showing five metrics: Follow-ups per decision, Time to decision, Context re-explained, Work stuck in waiting on, and Re-triage frequency](https://www.alknoma.com/res/img/blog/blog-11-1.png) *Five signals to track when auditing your team's coordination tax.* **1) Follow-ups per decision** — How many messages does it take to get a clear answer and a next step? If it routinely takes more than a couple of follow-ups, you're not "collaborating," you're compensating for missing structure. **2) Time from question to actionable answer** — How long does it take to go from "what should we do?" to "here's the plan"? If this regularly stretches beyond a day, you're probably waiting on ownership or context more than the decision itself. **3) Context re-explained** — How often does the same information get re-summarised across threads, docs, and handoffs? If people keep re-stating basics, your workflow isn't capturing decisions; it's relying on memory. **4) Work stuck in "waiting on..."** — What percentage of active work is blocked by approvals, missing info, or unclear ownership? If "waiting on" becomes a default state, you don't have a speed problem; you have a coordination problem. **5) Re-triage frequency** — How often does work get rerouted because the handoff wasn't clear? If tasks bounce between people or teams, your workflow is leaking accountability. ### Example: reducing follow-ups in a GTM handoff **What broke:** A GTM team needed 10+ messages per lead handoff just to clarify basics ("what's the onboarding status?", "did they sign the NDA?", "who owns next step?"). **What the audit showed:** - Follow-ups per handoff were consistently high - The "qualified → next step" gap was stretching into days - The same context was being re-explained repeatedly **What changed:** - Context moved with the handoff (latest CRM info attached, not requested) - Ownership was explicit (who owns it now, and what triggers the handoff) - Timing rules existed ("if no response in 24 hours, escalate to backup owner") **What improved:** Follow-ups dropped dramatically, handoffs stopped bouncing, and next steps became predictable because the workflow stopped leaking. ## Practical steps to reduce coordination drag today You don't need a new tool or a six-month overhaul to start reducing coordination tax. Here's what you can do this week: ### 1) Map the workflows that keep leaking time Pick the 2–3 flows that consistently feel painful (handoffs, onboarding, sprint planning). For each, write down: - where context lives (and where it gets lost) - who owns each step (and where it stalls) - what timing expectations exist (and where delays pile up) - what approvals are required (and who becomes the bottleneck) ### 2) Run a one-week mini audit Choose one workflow and track it for a week. Count the follow-ups, re-summaries, blockers, and reroutes. Then share the punchline with the team: "We spent X hours this week just unblocking and re-explaining." ### 3) Apply the stability levers Don't "motivate people" harder. Fix the workflow: - capture decisions where everyone can find them - make ownership explicit at every handoff - add timing rules and escalation paths for async work - set approval gates that reduce risk without creating stalls - surface status so people stop chasing it ### 4) Pilot a team agent on the worst friction A long-horizon agent inside Slack/Teams (like Ayven) is useful when it reduces the loops you're measuring: - summarising decisions and posting next steps somewhere durable - flagging work that's stuck "waiting on..." - nudging the right owner when handoffs go overdue - pulling relevant context forward so teams stop re-explaining The goal isn't to automate everything. It's to make the workflow stable enough that execution doesn't depend on constant chasing. ### 5) Re-check in 30 days Run the same audit again. If the tax is dropping, you'll see it: fewer follow-ups, fewer stalls, faster time to a real next step. ## The bottom line: busy ≠ productive Teams don't fail because they lack effort. They fail because the coordination tax, the fake work of follow-ups, nudges, and re-summaries drains their capacity without moving outcomes forward. Slack amplifies urgency but not throughput. AI tools save time on individual tasks but don't fix team-level friction. The solution isn't more tools or faster outputs. It's stable workflows: predictable handoffs, clear ownership, and context that's easy to find. Teams that reduce the coordination tax don't just feel more productive; they are more productive, because they're spending energy on execution, not alignment. If you're curious how we think about reducing coordination drag, you can read more about Ayven's approach here. The goal isn't to replace people; it's to make workflows stable enough that teams can focus on outcomes, not chasing context. --- # Why Most AI Tools Assume a Perfect World (And Teams Don't Work That Way) By Howard Chen (https://www.linkedin.com/in/howard-h-chen/), 9 February 2025. https://www.alknoma.com/blogs/why-ai-tools-assume-perfect-world A lot of AI workflows look brilliant in a demo and then quietly fall apart on a Tuesday afternoon. Not because the model is "bad". Because the workflow assumes conditions your team almost never has: complete context, stable priorities, clean data, and a human who replies instantly with a crisp yes/no. If you're on a 5–20 person product or GTM team, you'll recognise the pattern immediately. Someone asks an agent to draft a spec, write a customer email sequence, or triage inbound leads. The agent produces something fast. For a moment, it feels like relief. Then the real work begins. People hunt for missing context. Contradictions appear across tools. Approvals stall. Outputs get reworked because the underlying decision changed while everyone slept. What looked like speed turns into a longer review cycle than before. The operational pain is rarely dramatic. It's death by small frictions. Decisions live in a Slack thread, a half-updated Notion page, and a Jira comment from last week. An agent "finishes" its task, but nobody is clearly responsible for the next step. Legal, finance, or a busy founder becomes the bottleneck, and the team is spread across time zones. When AI-driven workflows fail in this environment, it's tempting to blame the model. In practice, most failures are simpler and more stubborn. They come from idealised assumptions about how work actually happens. ### Key Takeaways - Most AI tools are designed for ideal conditions, not real team workflows. - Missing context doesn't just slow teams down; it compounds rework and coordination debt. - Human delays and async approvals are normal operating conditions, not edge cases. - Speed without adaptability doesn't save time, it pushes the cost downstream. - Good agents help work complete by pausing, clarifying, escalating, and recovering when reality intervenes. ## The "perfect workflow" myth Most AI tools are built around an idealised picture of work. Inputs are complete. Steps are linear. Decisions are instant. Integrations behave exactly as expected. This isn't malicious; it's convenient. It's also why those workflows collapse the moment real people touch them. Demos mirror how leaders want work to happen: clear inputs, tidy handoffs, clean outputs. You see "final PRDs", stable pipelines, and instant approvals. In five minutes, the workflow reaches a satisfying conclusion. But early-stage teams don't buy AI tools because their workflows are already clean. They buy them because they're under pressure. Headcount is tight. Hiring feels slow and risky. Shipping, revenue, and pipeline targets don't wait. Speed becomes the purchase criterion. If an agent can generate a PRD, a campaign outline, or a report in seconds, it looks like a shortcut around resourcing. For a brief period, that belief holds. Drafts appear. Summaries land. Work feels lighter. Then friction shows up in the seams. Reviews drag. Outputs bounce back. Someone asks which version is correct. Another person flags that the CRM field isn't reliable. A stakeholder points out that positioning changed yesterday. The agent isn't failing at language. It's failing at coordination. ## Where idealised workflows break in real teams In real teams, breakdowns tend to cluster around a small number of predictable patterns. The good news is that these aren't edge cases. They're normal operating conditions. ### Missing context Context almost never lives in one place. Decisions are scattered across Slack threads, meeting notes, ticket comments, CRM records, and half-written documents that never quite became "official". Important constraints are often informal and unstructured: "Legal were nervous about this last time" or "We promised this customer we wouldn't do that again." A common product scenario looks like this: an agent drafts a PRD from a meeting transcript. It includes requirements that were described as tentative. Later, a Jira comment narrowed scope. Acceptance criteria live in a Figma annotation. Edge cases were discussed in a Slack thread with support. Unless the agent is explicitly guided, it can't see the contradictions. Downstream, engineering reviews the spec and flags gaps. The document bounces back. The agent is asked to "update it", but now there are multiple versions and no agreed baseline. The same pattern shows up in GTM work. An agent drafts outbound messaging based on last quarter's positioning doc. Meanwhile, the website headline changed last week and sales is using a different talk track. The output is fast, but misaligned, so the review cycle expands. ### Shifting priorities Small teams change direction constantly. A founder call reshapes the roadmap. A key customer escalates a bug. A competitor launches a feature. The backlog is reordered. Idealised workflows assume stability: gather inputs, produce output, ship. Real workflows are iterative. Work often sits in limbo while priorities are renegotiated. If an agent can't detect that the world changed, its "finished" output becomes stale mid-flight. Teams either ship the wrong thing or spend time manually auditing every line to figure out what still applies. ### Ownership gaps and handoffs Most work doesn't fail because nobody can write. It fails because nobody can decide. Ownership is often fragmented across tools. In Notion, the PM is listed. In Jira, the EM is the assignee. In Slack, the founder is making calls. The agent completes a task, but no one is clearly accountable for the next decision. In GTM teams, the same thing happens with inbound leads and campaigns. CRM fields are inconsistent. Routing rules change as the team learns. Without clear ownership and escalation paths, the agent either pushes work forward incorrectly or creates a queue of "needs review" that nobody owns. Work looks done, but it can't move forward. ## Human delays are the operating system Most workflow tools treat waiting as failure. In reality, waiting is the system. Approvals, reviews, stakeholder availability, and time zones stretch work into long tails. In async teams, a question asked late in the day in London might not be answered until the next morning by someone in San Francisco. This isn't hypothetical. Research in interruption science shows that knowledge workers are interrupted roughly every 6–12 minutes, fragmenting focus and quietly turning coordination into a tax that compounds across the day. Waiting also changes the state of the world. While you're waiting for legal sign-off, a competitor might announce something, a customer might escalate, or a stakeholder might change their mind. Naive automation responds badly to delay. It either acts without permission, creating risk, or stalls silently, creating confusion. Blocked work turns into hidden queues. Threads get reopened. Clarification loops repeat. Good systems tolerate delay and make it visible. They surface what's blocked, who owns the next decision, and when escalation should happen. Waiting isn't eliminated; it's managed. ## Why adaptability matters more than speed Speed is attractive because it's easy to measure and easy to sell. Faster execution feels like progress. But faster execution of wrong assumptions doesn't create leverage; it multiplies errors. A fast but brittle agent produces drafts that trigger long review cycles. People argue about assumptions. Someone notices a missing constraint late. Revisions introduce new inconsistencies because the underlying context was never stabilised. Adaptability is what actually saves time. Adaptable agents pause when inputs are insufficient. They ask targeted clarifying questions instead of a vague "need more context". They escalate decisions to the right owner instead of guessing. They recover cleanly when priorities change. That pause can feel like friction. In practice, it reduces total coordination time. It also reduces the emotional cost: fewer "why did you do that?" moments, fewer late-night fixes, fewer awkward customer corrections. Speed still matters, but only when applied to the right things: low-risk repeatables, verification steps, and status updates. When speed outpaces governance, teams pay in rework and lost trust. ### The demo wiring trap You can see this same mistake in how many "agent" systems are wired today: they optimise for what works when a human is watching, not what keeps going when nobody is. A common approach is to rely on pre-packaged tools and prompt packs, often exposed through things like Model Context Protocols. These work well when there's a human actively driving the interaction: selecting tools, correcting mistakes, and re-prompting when something goes sideways. The trade-off shows up when you try to run that setup unattended. Loading large sets of tools upfront increases context overhead, wastes tokens on instructions that aren't needed for the task at hand, and introduces failure modes you don't control because those tools are maintained elsewhere. That's fine for interactive productivity. It's brittle for long-running automation, where precision, context efficiency, and predictable behaviour matter more than feature count. The system isn't failing because the model is weak, it's failing because the workflow assumes a human will be there to notice and correct the deviation. ## What you should expect a good agent to do A good agent doesn't pretend it has the full picture. It assumes context is partial, sometimes wrong, and often out of date. So it checks where decisions actually live before acting. When the source of truth is unclear, it surfaces the gap instead of quietly filling it in with guesswork. It doesn't make decisions by accident. When judgement or approval is required, it routes the question to the right owner with enough context to respond quickly and with a clear recommendation, rather than dumping an open-ended ask into someone's inbox and calling that progress. It's designed for async reality. People are offline. Approvals take time. Silence is not consent. Waiting states are explicit, follow-ups are intentional, and stalled work doesn't disappear quietly into the system. It respects governance without turning everything into ceremony. Drafting is cheap. Execution isn't. A good agent knows the difference, avoids high-risk actions without sign-off, and leaves a trail humans can actually follow when something changes. And when things get ambiguous, it doesn't power through. It pauses, flags uncertainty, and hands off cleanly. The goal isn't to look decisive, it's to avoid creating rework, risk, or cleanup later. That's what "moving work forward" looks like in practice: not perfect automation, but fewer stalled handoffs, fewer clarification loops, and fewer silent failures that only show up days later. Put differently: if an agent looks impressive in a demo but can't do these things consistently, it's not reducing work, it's just moving the mess around faster. ## The reality-ready execution checklist Use this as a lens for evaluating agent behaviour in real workflows. ![Evaluating Agent Behaviour in Real Workflows - circular diagram showing five criteria: Persistent context, Ownership clarity, Timing awareness, Governance discipline, and Safe failure](https://www.alknoma.com/res/img/blog/blog-10-1.png) *Five criteria for evaluating whether an agent can handle real-world team workflows.* **Persistent context** — Does it work from current, agreed sources of truth and clearly signal when the context it's using may be stale or incomplete? **Ownership clarity** — Does it know who is accountable for decisions and escalate deliberately when ownership is ambiguous, instead of guessing or blocking progress? **Timing awareness** — Does it make waiting visible, manage follow-ups, and escalate when work stalls, so delays are handled, not hidden? **Governance discipline** — Does it separate drafting from execution and require approval for actions that carry customer, revenue, or compliance risk? **Safe failure** — When inputs conflict or uncertainty is high, does it stop, surface the issue, and route it to a human, then improve as the same patterns repeat? ## What reality-ready execution looks like If you work in a small, distributed team, this is worth stopping on for a moment. When people are offline, overloaded, or spread across time zones, does work still move? Or does progress quietly depend on someone being around to chase, clarify, or patch over gaps? When agents behave well in real conditions, the difference shows up in unglamorous places. Fewer tickets sitting in "needs review" with no clear next step. Fewer clarification loops where the same question gets asked in three different tools. Fewer rewrites caused by context that surfaced too late. Cycle time becomes more predictable, not because everything is faster, but because waiting is visible and managed. Work doesn't vanish into gaps. Decisions don't get lost between systems. Ownership stays clear even when people aren't immediately available. The goal isn't more output. It's fewer things getting stuck halfway. That's the gap between AI that looks impressive in a demo and AI that still holds up on a Tuesday afternoon. That's the problem we're focused on at Alknoma: building agents that adapt to how teams really work, instead of asking teams to contort themselves around brittle, idealised workflows. --- # The Real Cost of AI: Sunk Costs, Rebuilds, and Workflow Debt By Howard Chen (https://www.linkedin.com/in/howard-h-chen/), 5 February 2025. https://www.alknoma.com/blogs/ai-sunk-costs-rebuilds-workflow-debt Modern startup teams love to talk about AI-powered workflows. If you're in a 5–20 person company trying to ship faster, you've probably added automation or a "smart" tool to relieve the pressure. On paper, it makes sense: let AI handle the busywork so a small team can move faster without hiring. In practice, things get messier. The initial productivity bump rarely lasts. Beneath the demos and early wins, hidden costs start to pile up. Work feels more fragmented, coordination gets harder, and progress stalls in ways no dashboard tracks. AI often ends up accelerating a broken system instead of fixing it. The uncomfortable truth is that AI doesn't repair broken workflows, it exposes them. And once teams have invested time, effort, and belief into a setup, they tend to double down rather than step back. That's how sunk costs take hold, rebuild loops begin, and workflow debt quietly accumulates. This article looks at why that keeps happening, and what it *actually takes* to break the cycle. ### Key Takeaways - Most teams don't walk away from broken AI setups. They double down, because too much time and effort has already been sunk. - The real cost of AI isn't the licence. It's the rebuilds, retraining, and coordination work no one ever counts. - Sunk cost quietly drives AI decisions long after it's obvious the workflow isn't holding up. - Workflow debt builds when automation depends on perfect timing, constant availability, and people behaving predictably. - AI only creates durable value when workflows are built to adapt as teams, context, and conditions change. ## Why teams keep investing in broken AI AI is everywhere. Real results… much less so. Most companies are experimenting with AI in some form, but many leaders still can't point to clear revenue gains or cost savings. And yet teams keep piling on more tools, more automations, more experiments. Why? Hype, mostly. And fear. We've all seen the promises, 30%, 40%, even bigger productivity gains. Some teams do see an initial spike in output when AI rolls out. That's enough to make no one want to be the team that "missed the wave." But those early wins don't always hold. Upwork's research shows that many employees who report productivity gains from AI also report higher levels of burnout. Work speeds up, expectations rise, and suddenly the team is running hotter just to keep up. Still, very few teams stop. By that point, they've paid for licences, spent weeks integrating tools, trained models, built prompts, and rewired workflows. Walking away feels like throwing progress away, even when progress is questionable. I've spoken to founders who know their AI setup is fragile. Data pipelines break. Outputs need constant cleanup. Workflows stall the moment someone logs off. But they keep pushing, hoping the next version will fix it. That's not optimism. It's sunk cost. And it's one of the quiet reasons AI adoption keeps growing while real productivity gains lag behind. ## The sunk cost fallacy trap The sunk cost problem isn't complicated. It's the quiet thought that says: "We've already put too much into this to stop now." In AI, that thought is everywhere. Teams spend months onboarding a tool. Training it. Tweaking prompts. Bending workflows around its limitations. Eventually it does *something*, maybe 10–15% of the job. Not great, but not useless either. And that's where things get dangerous. Because once a system is "good enough," walking away feels worse than sticking with it. Even when a newer option could do far more with far less effort, it's hard to admit that the last six months didn't really move the needle. I've seen this play out repeatedly. Founders know their AI workflows are fragile. Outputs need constant cleanup. Automations break the moment reality shifts. But they keep going. Not because it's working, but because stopping would mean admitting it never really did. So teams tolerate clunky workflows. Manual handoffs. Half-automated processes that only work on a good day. Licences renew. Engineers keep patching. Complexity piles up. What looks like momentum is often just inertia. ![When AI Hits Reality - diagram showing ideation cycle where missing context triggers rebuilds, iteration phase with diminishing waves, and momentum quietly fading](https://www.alknoma.com/res/img/blog/blog-9-1.png) *The Sunk Cost Fallacy: Workflow debt builds when automation can't adapt to missing context, delays, and real team behaviour.* And the irony is brutal: by clinging to "okay" AI, teams burn more time and money than if they'd cut their losses early. The system never quite delivers, but it's expensive enough, in effort and ego, that no one wants to pull the plug. The simplest question most teams avoid is also the most useful one: *If we weren't already invested in this setup, would we choose it today?* If the answer is no, the problem isn't the model. It's the cost of pretending progress is happening. ## Invisible rebuild loops and workflow debt Even when teams don't fully abandon a tool, they usually fall into a quieter trap: rebuild loops. The workflow isn't fundamentally sound, so people keep patching it, manual checks, edge cases, "quick fixes" that somehow become permanent. The automation still exists on paper, but it needs constant supervision. That invisible effort compounds. This is workflow debt: operational drag that builds interest over time, much like technical debt. The pattern is familiar. A workflow looks clean in a diagram, until it depends on a person. Let's call him Bob. Bob holds a key piece of context. He's in another time zone. Or in meetings all day. Or just not available yet. The AI workflow still tries to move forward, but the information isn't there. So it stalls. Or worse, it ships with gaps. Later, someone has to step in, rerun the workflow, fix the output, and explain what changed. The work gets done twice. No one planned for it. Everyone feels it. This isn't an edge case, it's daily reality. McKinsey reports that employees spend 1.8 hours every day, over nine hours a week, just searching for information. Put differently, companies hire five people, but only four are doing productive work; the fifth is off hunting for answers that should already exist. Over time, these small rebuilds pile up. Teams don't notice because it looks like normal work: extra checks, late fixes, rework squeezed into the margins of the day. But zoom out and the cost becomes obvious: slower delivery, repeated effort, and growing fatigue. Gartner predicts that over 40% of agentic AI projects will be cancelled by the end of 2027, not because the models fail, but because the workflows and operating assumptions behind them don't survive real-world change. That's the real cost of AI most teams never budget for. Not the licence. The debt. The rebuilds. The quiet erosion of momentum when systems can't adapt to how work *actually happens*. ![The Real Costs of AI infographic showing four categories: Rebuilds and Retuning (hidden costs of keeping up), Sunk Costs (time and spend already gone), Delicate Workflows (timing and inputs that can't be missing), and Constant Chasing (automation that relies on people)](https://www.alknoma.com/res/img/blog/blog-9-2.png) *The real cost of AI isn't the licence. It's the rebuilds, retraining, and coordination work no one ever counts.* ## Adaptive workflows: Reducing drag and fatigue If there's one lesson teams keep relearning, it's this: you can't bolt AI onto a broken workflow and expect productivity to magically appear. Real gains don't come from smarter models. They come from workflows that can bend when reality changes. People go offline. Information arrives late. Decisions pause. Adaptive systems expect this. Rigid automation doesn't, and it breaks the moment conditions aren't perfect. The research backs this up. McKinsey found that only 21% of companies actually redesign work around AI. Those teams saw dramatically higher productivity. Everyone else is stuck running pilots, rebuilding workflows, and slowly losing trust, burning credits and credibility in the process. The difference isn't ambition. It's design. Adaptive workflows treat missing information as normal, not as failure. If Bob hasn't replied yet, the system doesn't stall or guess, it waits, reroutes, or flags the gap. No silent failures. No double work later. We learned this the hard way and started building explicit "waiting" states into our own workflows. Progress didn't speed up overnight, but it stopped collapsing. Good workflows also surface context where the work happens. Most rework comes from hunting for the "latest" doc, the right thread, the missing decision. When knowledge is attached to the workflow instead of scattered across tools, execution gets lighter. That's how you pay down workflow debt instead of compounding it. And here's the part most AI demos ignore: humans aren't infinitely elastic. If your system assumes people will sprint faster just because AI can, you're designing for burnout. Adaptive workflows respect timing. If something finishes at 10pm, it can wait until morning. That's not softness, that's sustainable performance. This thinking is what led us to build Ayven. Not another tool. Not another dashboard. An agent designed to work the way teams *actually do*. Pausing when context is missing, picking back up when it's available, and keeping work moving without constant babysitting. The hidden cost of AI isn't the licence. It's the rebuilds. The rework. The quiet exhaustion of fixing "automated" systems that never quite close the loop. Those costs don't have to stay hidden. If AI feels like it's slowing your team down, don't reach for a better model. Rethink the workflow. That's where the real leverage is. ## The real takeaway AI doesn't create workflow debt. Reality does. Distributed teams, async work, shifting priorities, and human unpredictability aren't edge cases to be engineered away. They're the default conditions most teams operate in. The problem is that many AI systems are built as if those conditions don't exist, assuming perfect information, stable ownership, and uninterrupted execution. That's where the hidden costs pile up. Sunk costs form when workflows break and teams feel compelled to rebuild instead of rethink. Rebuild loops emerge when automation depends on brittle assumptions. Over time, that drag compounds into workflow debt — work that looks automated on paper but quietly consumes more time to maintain than it ever saved. The future of productive AI isn't about generating more output, running faster models, or layering tools on top of broken systems. It's about designing AI that understands collaboration, respects timing, and adapts when work inevitably changes. That's when rebuilds slow down. That's when sunk costs stop accumulating. And that's when AI finally starts doing what it promised: helping teams move work forward, instead of weighing them down. ## What sustainable work actually looks like If you work in a distributed, online-first team, this is worth pausing on. Does your async setup *actually work* when people are offline, busy, or in different time zones? Or does progress quietly depend on everyone being available at the same time? The next generation of high-performing teams won't be defined by longer hours or faster output. They'll be defined by systems that keep work moving without constant chasing, rework, or context loss. That's the problem we're focused on at Alknoma — building automation that adapts to real team dynamics, instead of forcing teams to adapt to brittle workflows. Related reading: the productivity side of this is covered in [how much time AI really saves](/blogs/ai-productivity-truth-time-savings), and the systemic version in [AI workflow debt](/blogs/ai-workflow-debt). ## Frequently asked questions ### What is the real cost of AI for teams? The headline cost is the subscription, but the real cost is hidden: sunk-cost investment in brittle setups, repeated rebuilds of automations that break, and the workflow debt that accumulates in the seams between tools. These compound in time and attention long after the tool is paid for. ### What is the AI sunk cost fallacy? It's when a team has invested so much time and money into an AI setup that abandoning it feels like waste, so they keep patching a broken system instead of cutting it. The past spend is gone either way; the rational move is to judge the setup on whether it still pays off going forward. ### What are AI rebuild loops? Rebuild loops happen when, instead of fixing the seams of a brittle automation, someone rebuilds it from scratch. Each rebuild creates a fresh island of value plus a new set of seams to maintain, so effort keeps getting spent without the system ever stabilising. ### How do teams break the cycle of AI workflow debt? Make the debt visible, fix the handoffs between tools rather than adding features, give context a place to live so people stop re-asking, and cap the number of in-flight automations so flows actually get finished and owned. --- # Meet Ayven: Alknoma's AI Automation That Turns Busy Work Into Real Outcomes By Howard Chen (https://www.linkedin.com/in/howard-h-chen/), 9 January 2025. https://www.alknoma.com/blogs/meet-ayven-ai-automation-busy-work-outcomes At Alknoma, we weren't trying to reinvent work. We were mostly just trying to survive it. We work in Tech ourselves, and we learned that the promise of a flexible, online workplace with coworkers all over the world doesn't always create conditions for good work. It sounds great in theory. You have flexible hours to get work done. Digital tools recreate the office. And handoffs across time zones should work like a well-oiled machine. You complete your workday. The next time zone finishes their part while you sleep. Everyone reconnects during the brief schedule overlap. There's just one problem: the coordination that eats up the day. This process depends on perfect conditions. What we actually experience is that pattern. You know the one… That pattern of constantly doubling back. People searching for clarity, the most recent document, the right person to loop in. All the follow ups, last-minute requests, rework, meetings that go nowhere, and the list goes on. Status updates are tracked, but the work itself stubbornly refuses to move forward. Employees are spending more time coordinating work than executing it. AI tools like ChatGPT, Microsoft Copilot, and Google Gemini were supposed to help. They generate content, but they also increase expected workloads. A human is still required to prompt and align every piece of AI content. Progress stalls every time someone logs off, breaking down asynchronous work cultures. **If this sounds like your team… We've been there.** The reality is AI will not ease workloads until businesses create AI that works for humans, not the other way around. Alknoma is changing this with Ayven, real AI automation built for team operations. Ayven works alongside you in Slack and Teams and connects with your digital tools to gain context of your workflows. Using your company's intelligence, it handles multi-step coordination and ships work for you, no chasing required. ## The problem with the modern state of work Asynchronous work—where employees work on their own schedules, without relying on real-time interaction—is heavily relied upon today. Nearly one-third of meetings are across multiple time zones, a 35% increase since 2021. With teams spread across time zones, async work is essential in theory. In practice, it's breaking down. We see three factors causing this. ![Diagram showing the problems with modern async work](https://www.alknoma.com/res/img/blog/blog-8-1.png) ### Async cultures stop work in its tracks Projects estimated to take days turn into weeks. Assignment instructions are unclear, and days are filled with micromanagement and random "quick questions" through messaging. Microsoft 365 data shows that employees are interrupted by a meeting, email, or notification every two minutes on average. Working across time zones makes this worse. Context gets lost in handoffs, causing work to stop. This isn't a small tradeoff. Many employees spend their days consumed by other people's agendas, cutting into the finite 4-hour focus window needed for meaningful work. Instead, they're forced to push real execution to the end of the day, when their brain power is gone. Then the real work begins, and teams are immediately met with blockers. Emails with 20+ recipients increased by 7% this year alone, signaling more complex projects and uncertainty around ownership in teams. ### Employees are trapped in Agile rituals To regain control, companies add process. They introduce rigid workflows like process documentation, assignment trackers, and standups. Work time is spent inside Agile rituals instead of actual delivery. According to Microsoft's 2025 Work Trend Index, 53% of leaders say that productivity must increase. At the same time, 80% of the global workforce, leaders included, report that they don't have enough time to complete their work. The math isn't adding up. No amount of process can close the gap when business demands are outpacing human capacity. ### AI tools are not helping async teams Let's talk about it. Tools like ChatGPT and Microsoft Copilot are hurting, not helping async teams. They appear like productivity boosters. The reality is quite different. According to The Upwork Research Institute, 81% of C-suite leaders say they've increased employee workloads because of AI. Meanwhile, 47% of employees say they don't know how to achieve the AI productivity that their bosses expect. While AI speeds up output, it also generates "workslop." The low-quality, passable work that ends up creating more work in the long run. All of this work is highly dependent on people. > AI gets you to 90% done and then it requires the same amount of time it would have otherwise taken to clean it up and achieve the last 10%. ### So this is where we landed The result is messy work that's hard to keep track of. Workflows refuse to close, boundaries erode, and work never truly ends in what's being called the Infinite Workday. What's needed isn't AI layered on top of this broken system to generate even more work. It's a new class of intelligent AI automation built to deliver real outcomes. Already, 81% of business leaders from a survey sample of 31,000 workers say they expect to moderately or extensively integrate an AI agent within their company in the next 12-18 months. ## Meet Your New Conversational, Strategic Partner: Ayven **AI automation for async teams who are tired of pretending it's working** Most work stops the moment a person signs off. And the work culture isn't really asynchronous if it depends on everyone being online at the same time. Ayven is built to create a digital work environment that doesn't bottleneck. Unlike other AI tools, it doesn't need prompting from a human. It works autonomously alongside your teams to move work forward. Think Claude Code, but for team operations. Ayven lives in Slack or Teams and integrates with your digital tools. Once granted access, it is continuously checking connected systems and documents to understand context, progress workflows, and initiate action. Ayven is activated by missing information or key decision points, where a live chat will launch to gather the right context and execute the next step. ![Ayven workflow automation diagram](https://www.alknoma.com/res/img/blog/blog-8-2.png) Its memory updates conversationally and continuously, it doesn't reset, to understand both immediate tasks and long-term projects. This context allows Ayven to: - Interpret each employee's intent - Spot their blockers - Prompt the right people for input - Research and monitor to answer strategic questions - Complete work with the same context you'd use Ayven uses a human-in-the-loop approach to gate sensitive actions that require work from colleagues. The automation will simply request your approval before proceeding to prevent unintended actions. When Ayven needs your input, it batches requests so you're not spammed with notifications. Once it receives its answer, it takes action to keep work moving after you've logged off, so you wake up to progress. ### Eliminate the time zone tax adding weeks to your project timelines Instead of forcing handoffs when the work is not quite ready and trying to catch colleagues before they log off, Ayven bridges the gap between you and your team members across time zones. Onboarding is simple. Ayven walks each employee through a short intro flow to learn their role, availability preferences, and working hours. The automation connects the dots across these relationships and retains this information as flexible constraints. From there, Ayven requests information when it's needed. Team members respond in their own time zone. Ayven resumes execution when enough context is available, eliminating the time zone tax. If someone is unresponsive, Ayven doesn't wait indefinitely. It reroutes requests to alternative stakeholders when appropriate and surfaces blockers back to users with clear context. If a workflow hits too many dead ends, Ayven pauses the action and notifies you to investigate. ### Execute work that's superior to other AI tools Right now, most employees aren't using AI to reduce their workload. The nature of their work has just shifted. They're prompting and editing AI-generated outputs that take just as long as starting from scratch. Ayven produces finished AI-executed work with all the nuance from your tech stack. The associate's research. Your colleague's notes. That back-and-forth with your manager. All of the activity that so often disappears in one-on-one chats or siloed teams. It uses your documents to complete strategic tasks like competitive research, customer analysis, and market synthesis. Its search queries pull up the correct information, flag if something is outdated, and fill in the gaps for fragmented notes, turning scattered knowledge into superior work. The result is AI outputs that close work loops and a workday that actually ends, so progress doesn't depend on you bringing work home with you. ## Integrations See Ayven in action by integrating with your digital workplace. It collects context from one system, acts in another, and reports back to you asynchronously. **Standard Plan (included):** - Slack - Microsoft Teams - Google Drive - Notion - Jira - Youtrack More integrations to come in enterprise knowledge and documentation bases. **Enterprise Plan:** For SaaS enterprises with complex needs, we offer custom integrations with your existing processes and applications. This is the difference between isolated improvements and unlocking hyperproductivity across the full digital ecosystem to achieve enterprise transformation. ## Data security and governance: Drive value, not risk Alknoma prioritizes high standards of data privacy and security. Users simply integrate their desired technology applications and all their proprietary data remains their own, in their own systems. What's unique about Ayven's data handling is that almost no client data is stored in Alknoma servers. No documents, raw conversation text, meeting transcripts, or chat logs are recorded. When an action requires user approval, the operation state briefly persists to resume the workflow. Upon completion of the workflow via approval, rejection, or resolution, the operational data automatically clears. Embeddings consisting of gibberish numerical vectors, and containing no raw text and no readable content, are used for semantic search. Collection access settings can be configured to enable broader cross-content semantic lookup without duplicating or storing raw data. All embeddings can be removed. Alknoma also provides a secondary Ayven interface for leaders who want to know what actions the automation is taking and the reasoning behind them, with optional levers to adjust behavior. This format provides oversight and control without burdening your team with yet another dashboard or tool that competes for their attention. ## The benefits of scaling AI intelligence with automation AI agents are already delivering major productivity gains. In PwC's 2025 AI Agent Survey, 66% of senior executives who have adopted an agent say they are already seeing increased productivity. Looking ahead, 71% agree that AI is advancing so quickly that agents will rival the capabilities of a human within two years. Seeing measurable value typically depends on what percentage of employees are leveraging the automation to help accomplish their daily work. Within this same study, 68% reported that half or fewer of their employees work with the agents. Alknoma unlocks this next frontier of AI productivity by giving all employees access to AI automation that helps them work optimally. With Ayven, enterprises are able to: - Prevent work from becoming siloed across teams, time zones, and projects - Remove a large class of manual work coordination - Scale AI intelligence to meet their capacity constraints - Reclaim time to execute human-led creative and strategic work - Accelerate project delivery Among 844 companies with mature AI deployments, current agent use, and the belief that automation is important to their ROI: - 71% say their company is thriving, compared to 39% globally - 55% say that they have capacity for more work, compared to 25% globally ## A lighter way to work If you work in one of these flexible, online-first work environments, it's worth considering. Does your async culture really scale across all time zones and teams? Or does it only work when everyone is quietly online at the same time? The most successful companies in the future won't be the ones asking their employees to work nonstop. They'll be the ones where work flows freely with automation that supports human agency, creativity, and productivity. That's the kind of work we're trying to make possible at Alknoma. --- # Why AI Workflows Break in Async Teams By Howard Chen (https://www.linkedin.com/in/howard-h-chen/), 4 January 2025. https://www.alknoma.com/blogs/why-ai-workflows-break-async-teams AI is often sold as a shortcut through complexity — a way to speed things up, improve coordination, and eliminate friction from modern work. But inside real teams, especially where people are dispersed, the reverse happens. Workflows don't fail because the AI is weak. They fail because the way teams actually work doesn't match the assumptions baked into most AI tools. This disconnect is getting harder to ignore. AI adoption is everywhere, but productivity gains aren't. Despite record investment and constant usage, most teams still struggle to show real improvement in how work actually moves forward. Research from the [Stanford Institute for Human-Centered AI](https://hai.stanford.edu/ai-index/2025-ai-index-report) points to the same pattern: AI is now embedded across day-to-day operations, but outcomes remain uneven and difficult to pin down. The issue isn't model capability. It's that most AI is being dropped into workflows that were never designed to support it. The uncomfortable truth is simple. **AI only works when teams already know how to work asynchronously.** Without clear delegation, shared context, and async-first habits, AI doesn't speed things up — it adds friction. AI creates leverage only when it adapts to how teams actually communicate, wait, and hand work off. The moment it assumes everyone is available, responsive, and aligned, the system starts to break. ### Key Takeaways - AI workflows break most often in teams that still rely on real-time coordination. - Async isn't a nice-to-have for AI. Without it, automation falls apart quickly. - Most failures come down to missing context, unclear ownership, or handoffs that were never defined. - Bigger models don't fix broken workflows. Systems that adapt to how teams work do. - AI works best when it supports collaboration, not when it tries to replace it. ## The hidden dependency no one talks about: async culture Most AI tools are built for a version of work that no longer exists. One where people respond instantly, information is always complete, and tasks move forward in neat, predictable steps. That assumption breaks the moment teams become distributed. Research into global teams from [Harvard Business School](https://www.library.hbs.edu/working-knowledge/global-talent-local-obstacles-why-time-zones-matter-in-remote-work) shows how fragile coordination becomes once work spans time zones. Even small scheduling gaps reduce real-time communication and add friction. As teams spread across regions, async work stops being a preference and becomes the default — whether teams are ready for it or not. In real async environments, progress depends on people being offline, information arriving late, and decisions stretching across hours or days. Context lives across documents, messages, and tools. None of this is unusual. It's normal. Without strong async habits, AI runs into dead ends fast. It waits for information that doesn't exist yet, asks the wrong people at the wrong time, or pushes work forward before the team is actually ready. What gets labelled as "AI failure" is usually something simpler: a mismatch between synchronous expectations and asynchronous reality. The tool isn't broken. The assumptions behind it are. ## Why synchronous habits break AI workflows Many teams describe themselves as async, but still behave as if everyone is always available. Tasks get delegated verbally in meetings. Decisions live in someone's head. Context only shows up once someone asks for it. The cost of this fragmentation is easy to underestimate. Work on modern teamwork from [Atlassian's State of Teams research](https://www.atlassian.com/blog/state-of-teams-2025) shows that knowledge workers spend a significant amount of time simply searching for information that already exists somewhere inside the organisation. When context is spread across conversations, documents, inboxes, and individual memory, both humans and AI are forced to guess. Over time, those guesses compound. Work slows down. Mistakes creep in. And workflows quietly degrade long before automation ever has a chance to help. In this setup, progress depends on quick clarifications and real-time back-and-forth. AI struggles here because it can't infer what was never written down. When ownership is vague, or critical information sits with a single person, automation becomes fragile. The moment that person is unavailable — in another time zone, in meetings, or simply offline — the workflow either stalls completely or moves forward with the wrong assumptions. This is where frustration starts. Teams blame the AI for being unreliable, when in reality the tool is exposing communication gaps that existed long before automation entered the picture. ## The collaboration gap: where AI actually fails This gap between activity and impact is now visible across enterprise AI adoption. Usage continues to rise, yet measurable returns remain rare. Many organisations talk about AI as "strategic", while still struggling to point to clear productivity outcomes. Commentary drawing on [research from the MIT Media Lab](https://fortune.com/2025/08/18/mit-report-95-percent-generative-ai-pilots-at-companies-failing-cfo) highlights this tension. Deployment is accelerating faster than real-world results. The issue isn't intelligence. It's that collaboration and workflow design haven't caught up. ![Diagram illustrating the collaboration gap in AI workflows](https://www.alknoma.com/res/img/blog/blog-7-1.png) There's a persistent belief that AI fails because it isn't smart enough. In practice, most failures happen for a simpler reason: collaboration is underspecified. AI depends on clear inputs, explicit delegation, shared definitions of what "done" actually means, and stable async rhythms. When those foundations are missing, the system doesn't know what to wait for, who to ask, or when it's safe to move forward. It keeps querying missing information, retries actions at the wrong moment, or generates output that creates even more work downstream. That's why AI so often adds work instead of removing it. Humans step in to review, correct, and re-coordinate what the system couldn't infer on its own. The workload doesn't disappear. It just shifts. ## When One Person Holds the Context, Work Stops We often see this play out as the "Bob bottleneck" — where one person becomes the blocker for the entire workflow. Bob holds key context. He works in a different time zone. He checks messages a couple of times a day. The workflow depends on his input — but the system has no idea when that input will arrive. Most tools handle this badly. They keep pushing tasks forward without the missing information, fail silently when something breaks, or force users to rebuild the workflow once Bob finally responds. The problem isn't Bob. It's that the system doesn't recognise absence as a valid state. Adaptive workflows treat missing context as expected, not exceptional. The workflow pauses instead of collapsing. Actions retry at the right moment. Momentum is preserved without constant human intervention. ## Where AI actually fits in team collaboration AI isn't a replacement for collaboration. It's a participant in it. When it works well, AI helps teams hold shared context, surface the right information at the right time, and reduce unnecessary follow-ups. It respects async boundaries instead of constantly pushing work forward. But this only works when workflows reflect reality. People are busy. Information arrives late. Work rarely moves in straight lines. The most common mistake organisations make is dropping AI into broken collaboration patterns and expecting the tool to fix them. AI doesn't repair weak communication. It amplifies it. Only when collaboration is designed with async reality in mind does AI start to deliver real value. ## Practical steps teams can take right now If teams want AI to genuinely support async work, the starting point isn't better prompts or bigger models. It's better habits. **Clear delegation matters more than most teams realise.** Tasks need explicit ownership, clear inputs, and a shared understanding of what "done" actually means. If a human would need a follow-up meeting to understand the task, an AI system will struggle even more. **Missing context should be treated as normal, not exceptional.** Good workflows pause, wait, and resume without collapsing. Absence isn't a failure state — it's part of how distributed work functions. **Writing things down clearly, once, also matters more than most automation tweaks.** AI amplifies whatever structure already exists. When documentation is vague or scattered, the output reflects that. It also helps to **map async dependencies**. Knowing where work depends on time zones, availability, or specific people makes it easier to design workflows that adapt instead of breaking under pressure. For a concrete playbook on this, see [how to reduce coordination overhead in remote teams](/blogs/reduce-coordination-overhead-remote-teams) without adding more meetings. And finally, teams need to **stop expecting AI to fix culture**. Tools don't create async habits. People do. AI only becomes effective once those habits are already in place. ## The real takeaway AI doesn't break workflows. Reality does. Distributed work, async communication, and human unpredictability aren't problems to be eliminated. They're constraints to be designed around. AI only creates value when it's built to operate inside those constraints — not when it pretends they don't exist. The future of productive AI isn't about more output, faster generation, or bigger models. It's about systems that understand collaboration, respect timing, and adapt to how teams actually work. That's where workflows stop breaking. That's where AI starts helping. Want the flip side of this? When these broken workflows pile up, they leave behind [AI workflow debt](/blogs/ai-workflow-debt) — the hidden tax of half-finished automations that quietly slows teams down. It's all part of the [coordination tax](/blogs/coordination-tax) — the time teams lose aligning work rather than doing it. --- # How Much Time AI Really Saves — The Truth Behind AI Productivity Claims By Howard Chen (https://www.linkedin.com/in/howard-h-chen/), 12 December 2024. https://www.alknoma.com/blogs/ai-productivity-truth-time-savings A lot of AI stories talk about productivity gains and massive efficiency improvements. In most examples, the "success" of an AI system comes down to two things: how much time it saves and how much money it cuts. But when you actually look inside real teams, almost none of that holds up. Teams aren't failing because they don't have the latest model — they're failing because the workflows break the moment the AI no longer understands what's happening inside the team. AI only creates real productivity when it adapts to the messy, shifting realities of how teams actually work — not the idealised workflows most tools assume. ### Key Takeaways - AI productivity often breaks down in real teams because most tools ignore context, timing, and human behaviour. - The AI paradox is real: more output usually leads to more review work, not more progress. - Adaptive, context-aware workflows are essential for AI to deliver meaningful time savings. - Real productivity happens when AI adjusts to the team — not when teams are forced to adjust to rigid tools. ## The real productivity story no one talks about AI companies love talking about productivity — "save 20% of your time," "double your output," "do in minutes what used to take hours." It sounds impressive, but there's a big gap between what teams are being promised and what actually happens in practice. A recent MIT study, State of AI in Business 2025, shows that 95% of enterprise GenAI pilots fail, and 78% of companies calling AI 'strategic' can't show any measurable ROI. That tells you everything: most AI tools don't save the time they claim to, and the moments you think you're getting more efficient are often the moments you're actually losing time. ## Where AI productivity claims fall apart When you look closely, the numbers start to fall apart — mainly because they ignore the real complexity of day-to-day work. Most AI tools overpromise on productivity because they measure the wrong thing. They focus on output — how much gets produced, instead of the work that actually matters: the reviewing, the follow-ups, the waiting, the coordination, and all the messy human context that determines whether anything moves forward. That's why people often feel more productive without being any closer to the outcome they need. A big part of the industry narrative is built on feel-good claims like "you'll feel more productive," "you'll produce more content," or "you'll generate ideas faster." But feeling productive doesn't mean you've saved any time. The real difference is simple: feeling productive means generating more output; being productive means the right work happened faster, with fewer blockers, and without creating downstream issues. Most AI marketing focuses on the former — real teams care about the latter. ## The AI productivity paradox: More output = more work to review AI creates a productivity paradox: it makes us feel faster and more fulfilled, yet often leaves us with more work. It's the part of technological change no one talks about — the messy, gradual, invisible side. Most AI tools generate more output, but they don't reduce the work that actually slows teams down. Ten drafts, multiple variations, endless options — someone still has to review, validate, and decide, and that "someone" is already stretched. In practice, AI increases the volume of work while humans still own the quality, so the workload shifts instead of shrinking. Managers end up acting more like editors of AI-generated content than strategists or decision-makers. And when you add it all up, the amount of time actually saved is often close to zero. ## Why AI workflows fail inside real teams One of the most common real-world failures looks something like this: a team builds an automated workflow that relies on information from multiple people, and everything works fine until one person becomes the bottleneck. ![The Bob Bottleneck - A team builds an automated workflow, everything works until one person becomes the bottleneck, so the workflow breaks and nothing moves forward](https://www.alknoma.com/res/img/blog/blog-6-1.png) *The "Bob bottleneck" — a single unavailable person stopping an entire AI workflow.* Let's call him Bob. Bob holds a key piece of information, but he's slow to reply — maybe he's in a different time zone, in a meeting, deep in focused work, or simply not available. The AI workflow still tries to fetch the data from Bob, but it doesn't exist yet, so the entire flow breaks. Nothing moves forward, no time is saved, and the frustration starts. AI only works when it has the right information at the right moment — the timing, the updates, the availability. The second someone doesn't respond, or the data isn't there, or the workflow depends on someone like Bob being instantly accessible, the whole system collapses. This is the part most AI tools don't understand: real teams run on culture, timing, context, and human behaviour. And this is why so many AI time-saving promises fall apart in practice. ## Context is the missing ingredient — and why adaptive workflows matter Most AI tools treat workflows as if they're perfect, predictable systems — but real teams are messy. Context is constantly shifting: who's available, who has the missing information, who's become the bottleneck, what's outdated, what's blocked, and what needs to happen next. Typical AI tools don't track any of this. They operate in a vacuum, assuming that all information exists, everyone responds instantly, and every task follows a clean, linear path. But that's not how real teams work, and it's exactly where time is lost instead of gained. This is where adaptive workflows make the difference. Typical AI tools run tasks instantly, but break the moment information is missing. They don't adjust based on team context, and they force users to rebuild flows manually whenever something changes. Adaptive agents work differently: they understand when key data isn't available yet, recognise when someone is busy or offline, retry actions at the right moment, and follow the actual rhythm of the team. They preserve the workflow instead of collapsing it. ![Comparison of Most AI tools versus Adaptive Agents - showing how typical AI tools fail when information is missing while adaptive agents understand context and preserve workflows](https://www.alknoma.com/res/img/blog/blog-6-2.png) *A comparison of AI tools that break without context and adaptive agents that keep workflows moving.* This is the real divide between automating outputs and automating outcomes. Meaningful productivity only happens when workflows don't break, people aren't forced to rebuild them, and the system adapts to the team — not the other way around. There's also a deeper problem most teams never consider: sunk costs. When a static AI workflow breaks because the way a team operates has changed, everything built into that workflow becomes unusable. The time spent configuring steps, training the system, and handling exceptions must be repeated from scratch. In many organisations, this means teams end up losing more time maintaining brittle workflows than they ever hoped to save. It's one of the hidden costs of corporate AI systems that aren't designed to adapt. ## Where AI actually saves time For AI to genuinely save time, it must survive the realities of how teams work — the delays, the missing context, the blockers, and the constant changes that don't appear in a clean process diagram. The truth is, AI only creates real efficiency when it reduces the work people actually do: chasing information, reviewing low-quality output, rebuilding broken workflows, and waiting for someone who has the missing piece. Most tools don't touch those parts. They generate more output, not more progress. A more realistic version of productivity starts with understanding where time is really lost. It's in the handovers, the follow-ups, the coordination, the things that depend on people rather than models. AI helps only when it adapts to those dynamics — when it knows someone is offline, when data doesn't exist yet, when the timing is wrong, and when the workflow needs to pause rather than break. That's why adaptive, context-aware systems matter so much more than bigger models or faster generation speeds. They don't just automate tasks; they automate the conditions that allow work to move forward. ### And this is the part the industry doesn't talk about: AI won't replace the messy realities of teamwork. It won't erase the bottlenecks created by people. It won't magically deliver the productivity numbers in the marketing slides. But when AI is built to understand how teams actually operate — their timing, their gaps, their constraints — it finally has a chance to deliver on the promise everyone keeps repeating. That's where meaningful time savings come from. That's where real productivity starts. And that's the direction the next generation of AI systems needs to move toward. ## Practical Steps Teams Can Take Right Now If you want AI to actually save time, there are a few practical steps teams can take right now: ### 1. Map where time is really being lost. Look closely at review cycles, handovers, missing information, and the moments where work stops because someone isn't available. These friction points matter far more than output volume. ### 2. Stress-test your existing workflows for context gaps. Pick one workflow and ask: What happens if the person with the missing piece of information isn't available? If everything breaks, you've identified the real failure mode — not the AI model, but the assumptions behind it. ### 3. Identify who holds the key knowledge. Most delays come from a small number of people — the "context holders." Understanding who they are and where the dependencies sit helps teams design workflows that don't fall apart when someone is busy, offline, or working differently that day. ### 4. Design workflows that can pause and restart, not collapse. Aim for processes that can wait, retry, or shift based on timing and availability. Even small shifts toward adaptability can save more time than trying to automate the "perfect" workflow. These steps won't solve every problem, but they create a more realistic foundation — one where AI supports how teams actually work, instead of how a workflow diagram assumes they do. ## About Alknoma Alknoma focuses on the parts of work that are often overlooked — context, timing, and how teams actually operate. The platform uses AI to organise knowledge, surface relevant information, and support workflows in a way that reduces bottlenecks and helps teams move more effectively. This connects to two related ideas: where the saved time actually goes ([AI workflow debt](/blogs/ai-workflow-debt)), and why the gains stall in distributed teams ([why AI workflows break in async teams](/blogs/why-ai-workflows-break-async-teams)). ## Frequently asked questions ### How much time does AI actually save? Individual tasks often get faster, but measured team-level time savings are far smaller than headline claims, because the saved time leaks back out into coordination: reviewing AI output, fixing handoffs, and re-checking work. The gain at the person level rarely shows up as a gain at the team level. ### Why don't AI productivity gains show up in results? Because productivity is a team property, not an individual one. AI speeds up isolated steps, but work still moves at the pace of the slowest handoff, the missing context, and the waiting in between. Those bottlenecks sit outside what most AI tools touch. ### Is AI a net productivity gain or loss? It depends entirely on whether the time saved on tasks is reinvested or lost to coordination overhead. Teams that fix their handoffs and context-sharing capture the gain; teams that bolt AI onto broken workflows often see it absorbed by rework and follow-up.