Flolah is taking a different approach. It is becoming a coordinated company execution system involving both AI employees and human employees, rather than an agent platform that stops whenever human knowledge or judgement is required.
The COO can turn an outcome into a goal plan, delegate research and preparation to AI specialists, and assign a judgement step to the right human employee. The human receives the original goal, the precise outcome they own, and only the relevant outputs from earlier steps. Their response resumes that exact goal rather than starting an unrelated conversation.
This changes the practical workflow. Consider an overdue invoice. An AI employee can collect the factual invoice history and prepare a brief. A collections specialist can contact the customer and record a negotiated payment date. Flolah can validate that the recorded outcome is substantive, continue the plan, and bring the consolidated result back to the CEO.
Accountability matters as much as delegation. Tasks have an ETA. Kanban moves from green to amber to red as the deadline approaches or passes. The task owner is nudged before a breach; the CEO can be escalated through in-app notification, email, or the configured COO WhatsApp channel.
Human and AI employees also share the company’s communication surface. Eligible colleagues appear in chat, reporting lines remain visible in My Org, and role-based access determines which AI employees a human can reach.
The goal is not to remove people from work. It is to prevent work from losing its plan, evidence, ownership, and continuity when a person becomes the best next actor.
Learn more in the Flolah documentation and explore the open-source project.
]]>Real organisations begin somewhere else: responsibility.
Before a person joins a company, we decide what they own, which systems they may access, who they work with, and when they must escalate. An AI agent needs the same clarity. Without it, intelligence becomes difficult to direct and even harder to trust.
Four elements turn an agent from a disposable assistant into a durable colleague: role, permission, memory, and accountability.
“You are a helpful research assistant” is a personality prompt, not a role.
A durable role defines purpose, expected outcomes, collaborators, constraints, and escalation conditions. A research agent should know whether it gathers sources, forms recommendations, or both. A finance agent should know which data is authoritative and whether it may only analyse transactions or also initiate them. A communications agent should know whether it can draft, schedule, or publish.
This clarity improves routing. When a founder asks for a market brief, the COO can delegate evidence gathering to Research and narrative preparation to Communications without making the founder coordinate every handoff.
Flolah represents AI employees as durable roles with workspace instructions and tool access. Its AI employee guide describes the identity files used for capabilities, boundaries, collaboration, tools, and long-lived notes.
An agent should receive enough authority to complete its job, but no more.
Reading customer records is different from editing them. Drafting an email is different from sending it. Preparing a deployment is different from releasing it. A system that treats these actions as equivalent forces leaders to choose between useless agents and dangerously broad access.
Permission design should start narrow. Grant tools to a role, limit their scope, observe repeated runs, and expand authority only when the workflow has earned trust. Consequential actions should include explicit human approval.
The objective is not to remove people from every loop. It is to reserve human attention for decisions where judgement and accountability matter.
Agents cannot operate as a company if the founder must repeat the same context in every conversation. They need durable knowledge about products, customers, terminology, policies, metrics, and previous decisions.
But generated text should not automatically become company truth. Useful memory distinguishes authoritative data from working notes and records where information came from. It also respects role-based access: a shared company does not imply that every employee sees every record.
Flolah's company knowledge guide explains how company context can be stored as structured Master Data, documents, and searchable knowledge rather than being buried in chat history.
When an agent produces a questionable result, a leader needs more than the final paragraph. Which role handled the task? What context and tools did it use? Which handoffs occurred? Was the result reviewed? Did a human approve the consequential action?
This is why boards, notifications, run history, and audit trails remain important in an AI-native company. They create a visible chain from intent to outcome.
Accountability also changes agent behaviour. A role that knows its work is attached to an owner, an outcome, and a review point can be evaluated consistently. Teams can improve the workflow rather than arguing about an isolated conversation.
Roles make permissions understandable. Permissions make autonomy safer. Memory makes work consistent. Accountability makes the system improvable.
Remove any one element and the organisation weakens. Memory without permissions leaks context. Permissions without roles become arbitrary. Roles without accountability are job titles without ownership. Accountability without durable memory produces repeated investigations without learning.
The future of agents will not be decided only by which model scores highest. It will be decided by whether organisations can give capable systems clear responsibility under trustworthy control.
Flolah is open source under the Apache License 2.0, so teams can inspect the operating layer in the agent-os repository. The hosted Flolah.cloud service remains commercial; the open-source notices explain that boundary.
Start with one specialist role, one real outcome, narrow permissions, approved company context, and a visible human review point. Explore Flolah or follow the first 15 minutes guide.
]]>It is much harder to create a company of agents.
The moment several agents work on the same outcome, the difficult questions stop being about intelligence. Who owns the task? Which agent has the right context? What may it change? How does work pass from one specialist to another? What happens when they disagree? Where can a human inspect the result and intervene?
These are organisational questions. Answering them requires more than a collection of prompts and chat windows. An AI-agent company needs an operating system.
Models are becoming increasingly capable at research, reasoning, writing, coding, and tool use. But capability alone does not create reliable operations.
A talented employee without a role, access policy, shared records, or reporting structure would struggle inside any company. Agents have the same problem. If every agent receives broad instructions and unrestricted tools, the system may look autonomous during a demonstration while remaining unpredictable in real work.
The operating layer determines how intelligence becomes useful. It gives agents an identity, places them inside a structure, connects them to trusted company context, records their work, and defines the boundaries within which they can act.
Without that layer, the human remains responsible for carrying context and coordinating every handoff. The agents may execute tasks, but the person is still the organisation.
An agent should know more than its name and personality. It needs a durable responsibility.
A research agent may be responsible for gathering evidence and documenting sources. A finance agent may validate figures against approved company data. A communications agent may transform verified information into a narrative, but lack authority to publish it. A COO agent may coordinate all three without receiving unrestricted access to every underlying system. In Flolah, these are durable AI-employee roles with a name, purpose, workspace instructions, and explicit tool access—not disposable chatbots. The AI employee guide shows how those roles and workspace boundaries are represented.
Clear roles improve both performance and safety. They reduce ambiguity about who should receive a task and make permissions easier to reason about. They also create accountability: when an output is questionable, the organisation can trace which role produced it, what context it used, and who approved the result.
This is why an agent definition should resemble a job description. It should express purpose, responsibilities, collaborators, tools, data access, decision rights, and escalation conditions.
In a chat-first system, delegation often means copying a prompt from one conversation to another. That is not a workflow; it is manual routing.
Structured delegation preserves the outcome, ownership, dependencies, status, and expected deliverable. A COO agent should be able to break a broad objective into specialist tasks, monitor their completion, reconcile the outputs, and return a single decision point to the human leader.
For example, “prepare our monthly investor update” is not one writing request. It includes validating performance data, explaining changes, collecting significant events, identifying risks, drafting the narrative, and requesting approval. Different agents may own each stage, but the work must remain connected to one organisational outcome.
The operating system is what holds that structure together. Flolah's COO delegation guide documents the practical model: give the COO a clear outcome, let it route specialist work with context, and follow the resulting work through Kanban and notifications.
Agents cannot operate as a company if every conversation begins from zero. They need access to durable company knowledge: customers, products, terminology, metrics, policies, previous decisions, and completed work.
But a single unrestricted memory pool creates a different problem. Not every agent should see every record, and not every generated conclusion deserves to become company truth.
Useful company memory therefore needs structure and governance. Some information belongs in authoritative tables. Some belongs in documents. Some is temporary working context. Some must be reviewed before it is reused. Access should follow the agent's role, and important changes should be traceable.
The goal is not for agents to remember everything. It is for the organisation to remember the right things, with clear provenance and appropriate boundaries.
Reading information, proposing an action, and executing that action are different levels of authority.
An agent may be allowed to analyse invoices without sending payments. It may draft a customer response without emailing it. It may prepare a deployment without releasing it to production. Treating these actions as equivalent makes autonomous systems unnecessarily risky.
An operating system separates capability from permission. It defines which tools each role can access, what scope they may operate within, and where human approval is mandatory. The safest default is usually narrow authority that expands only when the workflow has earned trust.
Human approval should not be an emergency brake added after automation. It should be a normal part of workflow design. The system should know which decisions belong to agents and which belong to people.
When agents work in parallel, activity becomes difficult to understand unless it is represented explicitly.
Leaders need a view of current tasks, owners, dependencies, exceptions, completed runs, and pending approvals. They should not need to open five conversations and reconstruct the state of the company from chat history.
Boards, notifications, stand-ups, run histories, and audit trails may sound like conventional management tools. In an agent company, they become the interface between human judgement and machine execution.
Good visibility does not mean watching every tool call. It means compressing routine activity and elevating the moments that require attention.
A company becomes more valuable when it can repeat what it has learned.
If an agent completes a useful process once, the instructions should not disappear into a conversation. The workflow should be refined, tested, given appropriate inputs and permissions, and made available for reuse.
Over time, these workflows become organisational capabilities: market research, onboarding, reporting, support triage, document review, campaign planning, or domain-specific services. Some remain internal. Others can be offered safely to customers, partners, or software systems.
This is where an agent company begins to compound. It does not merely accumulate conversations. It accumulates reliable ways of producing outcomes.
Flolah is designed around this organisational model, and its public user guide documents the system without requiring sign-in.
It provides a home for named agent roles, shared company knowledge, connected tools and workflows, natural-language delegation, Kanban visibility, notifications, approvals, run history, and controlled external access. A founder can direct the company in plain language while the operating layer keeps responsibilities and execution visible.
The aim is not maximum autonomy. It is useful autonomy under clear human control.
Flolah is also open source. The application source is available in the agent-os repository under the Apache License 2.0, while the hosted Flolah.cloud offering remains a commercial service. The open-source notices explain that boundary and list the major open-source components used by the platform. This gives teams a way to inspect how the operating layer works instead of treating it as a closed black box.
That distinction matters. Businesses do not need agents that act independently at any cost. They need systems that can take responsibility for defined work, operate within trusted boundaries, and involve people when judgement matters.
The next generation of AI-native businesses will not be differentiated only by the models they use. Many companies will have access to similar intelligence.
The advantage will come from how that intelligence is organised: the quality of the roles, the depth of company context, the reliability of workflows, the clarity of permissions, and the speed with which human judgement can guide the system.
Multiple agents do not automatically become a team. A team does not automatically become a company.
The missing layer is the operating system.
If you want to test the model rather than only read about it, begin with Flolah's first 15 minutes. The guide walks through company setup, meeting the COO, adding company knowledge, viewing delegated work on Kanban, and deciding which specialist roles to add next.
Start with one real outcome rather than a generic experiment. Ask the COO to research a market, prepare a customer brief, or coordinate a weekly operating update. Observe the handoffs, refine the roles and permissions, and keep the human approval point explicit. That small workflow is the foundation of a larger agent organisation.
Create specialist agents, delegate real work, preserve company memory, and keep consequential decisions under human control. Explore Flolah, read the documentation, or inspect the open-source code.
]]>Open Forum or go straight to GitHub Discussions.
Suggested starter threads:
The user guide stays at flolah.cloud/docs/.
]]>That is the wrong model for consequential work.
Approval is not evidence that an agent failed. It is a deliberate assignment of responsibility. The agent prepares, validates, and recommends; the human decides when authority, judgement, or accountability cannot be delegated safely.
The safest workflows distinguish between producing an action and carrying it out.
An agent can draft a customer email without sending it. It can prepare a payment without authorising the transfer. It can build a deployment without releasing it. It can recommend a policy change without making that change effective.
This separation allows agents to perform most of the labour while preserving human control over consequences.
Not every action deserves the same interruption.
Low-risk, reversible actions may run automatically inside narrow boundaries. High-impact, external, financial, privacy-sensitive, or difficult-to-reverse actions should require approval. The threshold should also consider novelty: a proven recurring workflow may receive more authority than a new one.
Useful questions include:
An approval request should compress the relevant context.
The human needs to know the proposed action, supporting evidence, important alternatives, identified risks, and what will happen after approval. They should not have to read an entire agent conversation or reconstruct the task from tool logs.
Good approval design improves both speed and decision quality. The agent performs the investigative work; the person receives a clear decision surface.
Rejecting an action should not terminate organisational learning.
Capture the reason, route the work back to the correct owner, and preserve the correction for the next run. Over time, repeated approval feedback should improve instructions, role boundaries, and workflow design.
Approval history is therefore part of company memory. It records how human judgement modified automated recommendations.
A button is not meaningful control if the approver lacks time, context, or a real alternative.
Approval theatre appears when every routine action requests confirmation, causing people to click automatically, or when a high-stakes request provides too little information to assess. Both patterns create the appearance of governance without its substance.
Use approvals sparingly, present them clearly, and attach them to genuine decision rights.
Trust should be earned through observed performance.
Begin with approval before execution. After repeated successful runs, allow low-risk actions within defined budgets or scopes. Continue surfacing exceptions and preserve the ability to audit what occurred.
This progressive model is more practical than choosing between fully manual and fully autonomous operation.
Flolah's public guide covers approvals and operating controls alongside agent roles, workflows, notifications, and budgets. The application source is available under Apache 2.0 in the agent-os repository, with licensing boundaries documented in the open-source notices.
The purpose of autonomous workflows is not to remove human responsibility. It is to concentrate human attention where responsibility matters most.
Build the workflow so agents handle preparation and routine execution, while people retain authority over consequential exceptions. Explore Flolah and start with the public user guide.
]]>A research workflow can become a market-intelligence service. A document-review process can become an API. A support-triage agent can receive work from external systems.
But publishing a workflow is not the same as exposing an endpoint. The organisational controls that made it trustworthy internally must travel with it.
External users do not need access to internal conversations or implementation details. They need a defined outcome.
A service should state what it accepts, what it returns, how long it may take, and which failure conditions are possible. Inputs should be validated and outputs should have a stable contract.
This forces the team to distinguish the real capability from the accidental details of its first implementation.
Every invocation should have an identity. The system must know which customer, partner, OAuth client, or internal service initiated the work.
Identity determines permission. One partner may access a public catalogue; another may invoke a private workflow using its own scoped data. An anonymous request should not inherit the authority of the internal agent that designed the service.
Flolah keeps services closed by default and supports controlled external access. Its AgentExchange documentation explains how capabilities can be published for discovery and invocation.
A published workflow should expose the smallest useful surface.
Do not allow external callers to choose arbitrary tools, prompts, filesystem paths, or internal agents. Accept a constrained input, run a governed workflow, and return a defined result. Keep internal credentials and company memory behind the boundary.
Rate limits, budgets, timeouts, and payload limits are part of the product contract, not merely infrastructure details.
Some agent services finish in seconds. Others perform research, media generation, or multi-stage review that may take minutes.
A safe service model should support both synchronous and asynchronous execution. Long-running work needs a durable run identifier, status visibility, completion notification, and a way to retrieve the result without repeating the operation.
This matters commercially as well as technically. Customers trust services that make progress and failure visible.
Publishing a workflow does not eliminate approval requirements.
An external request may produce a draft immediately while waiting for an internal person to approve release. The service contract should communicate that state honestly rather than silently bypassing governance.
Approval is especially important when outputs represent a company, use sensitive data, or trigger downstream actions.
An agent service needs logs, run history, ownership, cost visibility, and auditability. Teams should be able to answer who invoked it, which version ran, what resources it used, and why it failed.
Observability also improves the product. Real invocation patterns reveal confusing inputs, missing capabilities, and workflows that should be split or simplified.
The Flolah application source is available under Apache 2.0 in the agent-os repository. Teams can inspect how the operating layer represents agents, workflows, and service boundaries. The hosted Flolah.cloud offering remains commercial, as explained in the open-source notices.
Open source does not replace operational security, but it allows architecture and assumptions to be examined rather than hidden.
Start with a workflow that already succeeds internally. Define its contract, reduce its permissions, test failures, choose an approval policy, and publish it to a limited audience before expanding access.
Explore Flolah, read the AgentExchange guide, or begin with the public documentation.
]]>A founder says, “Prepare our monthly investor update.” Behind that sentence are several different jobs: validate the numbers, compare performance with the previous month, collect significant events, identify risks, draft the narrative, and request approval.
If the founder must personally move every fragment between agents, AI has accelerated tasks without reducing coordination. A COO agent changes that equation by owning the outcome and routing work to specialists.
Effective delegation starts with a result, not a list of disconnected prompts.
“Prepare our investor update using approved monthly figures, explain material changes, and flag anything requiring my decision” gives the COO an outcome, a source constraint, and an escalation rule.
The COO can then decompose the objective. Finance validates figures. Research gathers relevant market context. Communications drafts the narrative. The COO reconciles their work and returns one review point to the founder.
Flolah's COO guide recommends one clear outcome per message so specialist work can be routed with full context.
Breaking work into tasks is not useful if each specialist receives an incomplete version of the goal.
The finance agent needs to know the reporting period and approved data source. Research needs to know which developments are relevant to investors. Communications needs verified figures, audience expectations, and tone. Every task should remain connected to the parent outcome.
Structured delegation records that relationship. The organisation can see why a task exists, who owns it, which deliverable is expected, and what must finish before the next stage begins.
Delegation does not imply identical access.
Finance may read protected company data but lack permission to send messages. Communications may edit the report but not change source figures. Research may browse external sources while remaining unable to publish. The COO coordinates the workflow without necessarily gaining unrestricted access to every underlying system.
This separation makes the system safer and produces better work. Each agent operates with context and tools suited to its responsibility.
The AI employee guide shows how Flolah attaches purpose, workspace instructions, collaboration rules, tools, and memory to each durable role.
A founder should not have to ask every agent for a status update.
In Flolah, specialist work can appear as Kanban cards, while notifications surface exceptions and completed asynchronous work. The board becomes a shared representation of the outcome rather than a manager's private reconstruction of several chats.
The COO should remain quiet during routine execution and become visible when something is blocked, inconsistent, or consequential. This is coordination by exception.
Parallel work often produces conflict. Finance may flag a weak month while Communications drafts an optimistic narrative. Research may identify a market change that invalidates an earlier assumption.
The COO should not merely concatenate outputs. It should compare them, resolve straightforward inconsistencies, and escalate genuine judgement calls. A useful final response might say: “The update is ready. Revenue is verified, but one customer concentration risk needs your decision before publication.”
That is more valuable than receiving three polished documents and discovering the contradiction yourself.
Once the investor-update workflow succeeds, preserve it. Define the inputs, roles, sequence, approval point, and final deliverable. Schedule it monthly if appropriate.
The organisation has now learned a repeatable capability. The next run should begin with stronger context and require less coordination.
Flolah is open source under Apache 2.0; its implementation can be inspected in the agent-os repository. Product operation is documented in the public Flolah user guide.
Follow Flolah's first 15 minutes, meet the COO, and delegate one real outcome. Watch how the work is routed, refine the specialist roles, and keep the final approval with the human CEO.
]]>A founder could begin alone, but progress eventually created a familiar pressure: hire someone to research the market, someone to handle operations, someone to manage customers, and someone to keep everyone aligned. The organisation expanded because the work of coordinating work expanded.
AI changes that relationship.
It does more than make an individual faster at writing, analysis, or coding. Used as an organised system, AI gives one person access to specialised capabilities that can be delegated, coordinated, reviewed, and reused. The solo founder is no longer limited to a single stream of attention. One person can begin to operate like an organisation.
That does not mean replacing a company with a collection of chat windows. A chatbot can answer a question. An organisation must remember context, divide responsibility, track work, respect permissions, and know when a human decision is required.
The difference is coordination.
The first wave of generative AI focused on personal productivity. We asked an assistant to draft an email, summarise a document, or suggest code. Each interaction was useful, but isolated. The human still had to remember the objective, move information between tools, decide what happened next, and verify that the task was complete.
This model has a natural ceiling. If every action begins with a new prompt and ends with copied output, the person remains the workflow engine. AI helps with individual steps while coordination stays manual.
An agent organisation works differently.
Imagine asking a COO agent to prepare a monthly investor update. It breaks the outcome into distinct responsibilities. A finance agent validates the numbers against company data. A research agent gathers relevant market context. A communications agent produces the narrative. The COO reconciles their work, identifies exceptions, and returns one review point to the founder.
The founder still owns the decision. What changes is the amount of coordination they must personally perform.
This is the beginning of organisational leverage: not merely completing tasks faster, but allowing a small human decision layer to direct a broader system of specialised work.
Most agent demonstrations begin with intelligence: give a model a goal and let it reason. Real organisations begin with responsibility.
A useful agent needs a defined role. It should know what outcomes it owns, what information it may access, which tools it can use, when it can act independently, and when it must request approval. It also needs a relationship to other roles. A finance agent and a growth agent may use the same revenue data, but they should interpret it for different purposes and operate with different permissions.
This makes an agent's design closer to a job description than a clever system prompt.
The distinction matters because capability without boundaries is difficult to trust. A founder should be able to delegate research without accidentally authorising publication, or delegate invoice preparation without granting unrestricted financial access. Autonomy becomes useful only when authority is explicit.
Companies accumulate context. They remember how customers are classified, which metrics matter, how decisions are made, and what happened the last time a problem appeared.
Without persistent company memory, agents repeatedly rediscover the same facts. Instructions drift across conversations, outputs become inconsistent, and the founder becomes the only reliable source of context.
An agent organisation therefore needs more than chat history. It needs governed knowledge: structured company data, documents, operating rules, past decisions, and searchable work history. Agents should use shared context without confusing shared access with unlimited access.
Memory is what allows delegation to compound. A completed task should leave the organisation more capable than it was before.
When one person performs every step, progress is visible because the work is in their head. Once agents begin working in parallel, that visibility disappears unless the system deliberately restores it.
Founders need to know what is running, who owns each task, which inputs were used, where work is blocked, and what requires approval. Familiar operating tools—boards, notifications, run histories, and audit trails—become more important, not less.
The goal is not to watch every action. It is to preserve accountability while reducing supervision.
A well-designed system keeps routine execution quiet and makes exceptions obvious. Human attention is then spent where judgement has the highest value: setting direction, resolving ambiguity, approving consequential actions, and handling relationships.
Traditional organisations tend to have a narrow decision-making layer, a coordination-heavy middle, and a broad execution base. An AI-native organisation can take a different shape.
One or a few humans set intent and exercise judgement. Specialist agents plan and coordinate within defined roles. Tools and workflows handle repeatable execution. Instead of adding a person every time a new operational responsibility appears, the company can first create a capability, test it, govern it, and decide later whether human ownership is needed.
This does not eliminate people. It changes the point at which people become necessary.
Humans remain essential wherever trust, taste, accountability, negotiation, empathy, or high-stakes judgement dominates. But many early-stage companies hire partly because their founders cannot sustain the coordination burden alone. Reducing that burden lets companies remain smaller for longer and hire more deliberately.
Flolah is our attempt to make this model practical.
It is an operating system for an AI-agent company: a place to create named specialist agents, give them durable roles and company context, delegate work in plain language, track execution, insert human approvals, and turn successful workflows into governed services.
The central idea is simple: your company may be one person, but your team does not have to be.
We are not trying to build a pile of autonomous chatbots. We are building the organisational layer that makes multiple agents understandable and controllable: identity, memory, tools, work visibility, permissions, and accountability.
There are still difficult questions. How much autonomy should an agent receive? How should responsibility pass between specialists? Which memories should be shared? How do we evaluate work that is technically correct but commercially wrong? These are not peripheral product details. They are the management problems of an agent-native company.
The most interesting consequence of AI may not be that existing companies become more efficient. It may be that entirely new companies become possible.
A founder can test an idea with research, operations, support, and growth capabilities from the beginning. A specialist can productise expertise without first building a large service team. A small business can establish repeatable operating systems earlier than its headcount would normally allow.
The one-person company is not becoming a company without people. It is becoming a company in which human attention is concentrated at the point of greatest leverage.
That is a different kind of organisation—and we are only beginning to learn how to build it.
]]>The forum is hosted as GitHub Discussions on the public Flolah repository. Sign in with GitHub to ask a question, share a workflow, or reply to a post.
New posts are markdown in the public repo (docs-site/blog/). After a deploy they appear at flolah.cloud/blog/.
We have used Flolah's organisational model while shaping Flolah itself—giving work to specialist roles, preserving product knowledge, coordinating through a COO, and keeping consequential decisions with people.
The experience reinforced a lesson that agent demonstrations often miss. Generating work is not the hardest part. Organising responsibility is.
Broad roles produce broad answers.
When an agent is described only as “helpful” or “technical,” it must infer the objective, audience, boundaries, and definition of completion every time. The results may be impressive but inconsistent.
Durable specialist roles worked better. Research gathers evidence. Platform Help answers from product documentation. Workflow Builder handles visual workflows. The COO plans and delegates. Each role has a purpose and knows which peers exist.
The AI employee guide documents how Flolah stores those identities as workspace instructions, collaboration rules, tools, and memory.
We found that delegation works best when the human states one clear outcome.
“Document this feature, verify the behaviour, and flag decisions” gives the COO something it can decompose. A sequence of disconnected micro-prompts makes the human responsible for orchestration again.
The COO model is valuable because it owns the relationship between specialist tasks. Flolah's delegation guide describes how clear asks are routed with context and represented on Kanban.
Product knowledge cannot live only in the founder's head or in old chats.
Writing public documentation forced concepts to become explicit: what an AI employee is, how company knowledge works, which tools require configuration, and where approvals belong. That documentation then becomes usable context for both people and agents.
This creates a useful loop. Building improves the docs; the docs improve agent performance; agent questions reveal where the product remains unclear.
The Flolah user guide is public and requires no sign-in, so customers and contributors can examine the operating model directly.
It is easier to delegate when work does not disappear.
Kanban cards, notifications, stand-ups, and run history make background execution understandable. The founder can see whether a task is active, blocked, waiting for review, or complete without asking every specialist for an update.
Visibility also exposes weak delegation. If cards repeatedly stall, the issue may be missing context, unclear ownership, excessive permissions, or an approval placed at the wrong stage.
Some actions should remain drafts until a person approves them. Publishing an article, changing access, sending an external message, or deploying production code carries responsibility beyond the quality of the generated output.
We learned to treat approval as a normal workflow stage. Agents should prepare enough evidence for a decision, while the person retains meaningful authority to accept, reject, or revise.
This approach enables more autonomy because the boundary is visible.
Flolah's application source is licensed under Apache 2.0 and available in the agent-os repository. The hosted Flolah.cloud service remains a commercial offering; the open-source notices document the boundary and major components.
Publishing source does not make a product correct automatically. It does make design decisions inspectable. Contributors can trace how roles, permissions, tools, and workflows are represented and challenge assumptions with evidence.
The most important insight is that an agent company is not defined by the number of agents it runs.
It is defined by how clearly work moves from human intent to specialist responsibility, governed execution, visible progress, and human judgement. Models and tools will continue to change. A sound operating model makes those changes usable.
We are still learning. That is precisely why building Flolah with Flolah matters: every failure is not merely a product bug; it is evidence about how AI-native organisations need to work.
Try the first 15 minutes, inspect the open-source repository, and share what works—or breaks—in the Flolah forum. Explore Flolah.
]]>Why place machine-speed workers on a board invented for human teams? Because autonomy does not remove the need for shared state. It increases it.
When several agents work in parallel, activity disappears into conversations, tool calls, and background runs. A board restores a simple organisational truth: what are we trying to achieve, who owns each part, what is blocked, and where does a human need to decide?
Chat is excellent for expressing intent and resolving ambiguity. It is poor at showing the state of an organisation.
To reconstruct progress from chat, a founder must remember which agent received which request, open several threads, interpret partial replies, and determine whether work is waiting or complete. That cognitive burden grows rapidly when agents operate asynchronously.
A shared board separates conversation from state. The chat explains; the card records.
Every meaningful task should have an owner, an expected outcome, and a status.
That remains true whether the owner is a person or an agent. Explicit ownership prevents two specialists from assuming the other will act. It also prevents a coordinating agent from declaring an outcome complete when one dependency remains unresolved.
Flolah's Kanban and standups guide explains how delegated work appears on the board and how operating updates can be reviewed without reopening every chat.
A useful board is not merely a visual report for the founder. It is part of the coordination mechanism.
The COO can use status to determine what may proceed. Specialists can understand dependencies. Scheduled stand-ups can summarise progress and exceptions. The founder can intervene at the correct level rather than micromanaging tool execution.
The familiar columns—planned, active, blocked, review, complete—compress large amounts of activity into a state that both people and agents can reason about.
Most autonomous work should not demand attention. If every successful tool call creates a notification, the organisation becomes noisier than the manual workflow it replaced.
Boards and notifications should elevate exceptions: missing input, permission denial, contradictory evidence, budget threshold, failed run, or required approval. Routine progress remains visible when requested without interrupting the founder.
Flolah's notifications guide describes how the bell and digest surface work that actually needs attention.
A completed card is evidence. It links an outcome to its owner, timing, handoffs, and result.
Over repeated runs, that history reveals which workflows stall, which roles receive ambiguous work, and where approvals create unnecessary delay. The organisation can improve the operating system instead of simply retrying prompts.
This is one reason traditional management patterns remain relevant. AI changes who performs the work and how quickly it happens. It does not eliminate dependency, accountability, or learning.
Agent boards can become cluttered if every internal reasoning step becomes a card. Track organisational units of work, not hidden model mechanics.
“Validate monthly revenue” is useful. “Think about spreadsheet,” “call tool,” and “summarise cell values” are execution details better kept in run history. The board should remain legible to a leader making decisions.
The most important function of Kanban in an agent company is not project management. It is the boundary between human judgement and autonomous execution.
The founder can see where intent became work, where work became a deliverable, and where a decision is still theirs. That visibility makes it possible to delegate more without surrendering control.
Flolah's source is open under Apache 2.0 in the agent-os repository, and the operating model is described in the public documentation.
Use the first 15 minutes guide to meet the COO, delegate a real outcome, and watch the resulting work appear on Kanban. Explore Flolah.
]]>