<?xml version="1.0" encoding="utf-8"?><feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en"><generator uri="https://jekyllrb.com/" version="3.10.0">Jekyll</generator><link href="https://coland-g.github.io/feed.xml" rel="self" type="application/atom+xml" /><link href="https://coland-g.github.io/" rel="alternate" type="text/html" hreflang="en" /><updated>2026-05-29T23:27:01+08:00</updated><id>https://coland-g.github.io/feed.xml</id><title type="html">COLAND-G Notes</title><subtitle>AI tools, workflows, and experiments from real product building.</subtitle><entry><title type="html">In the AI Era, the One-Person Company Becomes the Smallest Execution Unit</title><link href="https://coland-g.github.io/ai/agent/organization/2026/05/29/one-person-execution-unit.html" rel="alternate" type="text/html" title="In the AI Era, the One-Person Company Becomes the Smallest Execution Unit" /><published>2026-05-29T00:00:00+08:00</published><updated>2026-05-29T00:00:00+08:00</updated><id>https://coland-g.github.io/ai/agent/organization/2026/05/29/one-person-execution-unit</id><content type="html" xml:base="https://coland-g.github.io/ai/agent/organization/2026/05/29/one-person-execution-unit.html"><![CDATA[<blockquote>
  <p>AI does not make one person magically omnipotent. It lowers the friction of moving work forward, making one accountable owner plus an agent stack a new smallest execution unit for many projects.</p>
</blockquote>

<p><img src="/assets/images/one-person-execution-unit-cover.png" alt="One accountable owner coordinating AI agents" /></p>

<p>I increasingly think the one-person company should not only be understood as a solo founder model.</p>

<p>It may also become the smallest execution unit inside future organizations.</p>

<p>In the past, when people talked about one-person companies, they usually meant independent founders, solo developers, or very small teams using software and automation to do work that previously required more people.</p>

<p>With AI agents, the meaning changes.</p>

<p>The question is no longer only whether one person can start a company. The deeper question is how many people are needed to start, move, and deliver a project.</p>

<p>I do not think the recent interest in one-person companies is only because AI suddenly gives people abilities they never had before.</p>

<p>The more important reason may be experiential.</p>

<p>People are feeling a new kind of relief: fewer alignment meetings, less waiting for someone else’s queue, less repeated explanation of the same context, and fewer handoffs where the original problem gets diluted.</p>

<p>One person can take an idea, turn it into tasks, send those tasks to agents, get a first result back, judge it, revise it, and keep moving.</p>

<p>The attractive part is not that one person becomes magically omnipotent.</p>

<p>The attractive part is that the friction of moving work forward becomes much lower.</p>

<p>In traditional organizations, even a relatively small project quickly becomes a multi-role process. Someone handles requirements. Someone writes product specs. Someone designs. Someone builds. Someone tests. Someone operates. Someone analyzes data. Someone manages progress.</p>

<p>That structure is sometimes necessary. Complex systems need specialization. High-risk work needs review and checks.</p>

<p>But it also creates a persistent cost: a large amount of organizational energy is spent on communication, alignment, explanation, waiting, follow-up, and handoffs rather than direct progress.</p>

<p>The important change in the AI era is that some work that previously had to be distributed across roles can now be delegated by one strong owner to a group of agents.</p>

<p>The smallest execution unit may shift from a small team to one accountable owner plus an agent stack.</p>

<p>That is what I mean by the one-person company becoming the smallest execution unit.</p>

<h2 id="the-problem-is-coordination-cost">The Problem Is Coordination Cost</h2>

<p>Many organizations are not slow because people are lazy.</p>

<p>They are slow because the work passes through too many translation layers.</p>

<p>Accountability closure matters more than visible activity.</p>

<p>A project can have many people involved, many meetings, many documents, and many updates, but still lack one person who truly owns the goal, judgment, progress, and result.</p>

<p>An idea becomes a requirement. The requirement becomes a design. The design becomes code. The code becomes a test report. The test report becomes a bug list. The user feedback becomes an operations summary. The summary becomes a dashboard.</p>

<p>Every layer does work. Every layer can also lose context.</p>

<p>The original question may be concrete: can we validate whether a certain customer segment will pay for an automation workflow?</p>

<p>After several handoffs, it may become a feature list, a timeline, several reviews, meeting notes, and many open questions.</p>

<p>Everyone has done their part, but the core thing the project was supposed to validate may become less clear.</p>

<p>The process may look complete, but responsibility has not closed the loop.</p>

<p>Middle management can help, but it can also create another coordination layer.</p>

<p>Many management activities exist because the structure itself creates friction: who owns this, what is blocked, what changed, what is next, when will it ship, and how do we judge whether it worked?</p>

<p>In the past, these costs were difficult to avoid because one person could not perform many specialized tasks alone.</p>

<p>AI agents change more than the supply of specialized capability.</p>

<p>They also change the friction of project movement.</p>

<p>Before, moving an ambiguous idea one step forward often required finding the right person, explaining the background, scheduling time, aligning expectations, and waiting for output. Now many early steps can be completed by one owner and agents first: research, a proposal, a prototype, early data, and a concrete result that can be reviewed.</p>

<p>This does not make human collaboration irrelevant.</p>

<p>It compresses a lot of low-value pre-coordination.</p>

<h2 id="one-owner-plus-agents">One Owner Plus Agents</h2>

<p>A more efficient project unit may start with one capable owner.</p>

<p>This person is not a superhuman who is the best product manager, designer, engineer, tester, operator, and data analyst at the same time.</p>

<p>The real requirement is project closure.</p>

<p>The owner can define the goal, judge what is worth doing, decompose ambiguous work, coordinate tools and agents, review quality, decide when to continue or stop, and own the result.</p>

<p>In this model, agents are not one magical assistant. They are a set of executable roles.</p>

<p>One agent can research. One can draft user interviews. One can help write a product plan. One can write code. One can test. One can summarize data. One can prepare social posts. One can create a review note.</p>

<p>The agents do not have to be perfect.</p>

<p>But they can absorb a large amount of first-draft, organization, generation, checking, and repetitive execution work.</p>

<p>The owner’s job is not to disappear from the process. It is to direct the process: set the target, decompose the work, assign tasks, review output, correct direction, and move the result forward.</p>

<p>The cost structure changes.</p>

<p>Before, the cost was coordination among people.</p>

<p>Now, more of the cost becomes task design, agent orchestration, review, and correction by one owner.</p>

<p>This is not simply AI replacing people.</p>

<p>It is a compression of low-value coordination into a smaller, faster, more accountable execution unit.</p>

<h2 id="the-hiring-standard-changes">The Hiring Standard Changes</h2>

<p>If this direction is right, hiring also changes.</p>

<p>Organizations will still need specialists. But the scarce people will increasingly be those who can close the loop on a project.</p>

<p>The question will not only be:</p>

<p>Can you write code?
Can you write specs?
Can you run growth?
Can you make dashboards?</p>

<p>The more important question will be:</p>

<p>If I give you an ambiguous goal, can you use AI to produce a first meaningful result in a week?</p>

<p>How do you decompose the problem?
How do you verify output?
How do you know when the agent is wrong?
How do you manage uncertainty?
How do you report progress and learn from the result?</p>

<p>The most valuable people will not be narrow role executors. They will be cross-functional project owners.</p>

<p>They may have one main specialty, such as product, engineering, growth, sales, operations, or consulting. But they cannot stay inside a narrow job boundary. They need business sense, product judgment, technical literacy, data awareness, and the ability to use AI systems as execution infrastructure.</p>

<h2 id="the-boundary-still-matters">The Boundary Still Matters</h2>

<p>This does not mean companies will become empty.</p>

<p>It does not mean every team disappears.</p>

<p>Complex business, regulated systems, high-risk decisions, physical operations, and deep professional work still need teams, review layers, and clear accountability.</p>

<p>The one-owner-plus-agents model has boundaries.</p>

<p>The work must be decomposable.
The result must be checkable.
Errors must be tolerable or reversible.
The owner must be strong enough to define goals and judge quality.</p>

<p>Agents amplify the owner.</p>

<p>They also amplify confusion.</p>

<p>If someone cannot define the objective, break down the work, review output, or take responsibility, adding more AI tools will only create more unfinished fragments.</p>

<p>So the point is not fewer people for the sake of fewer people.</p>

<p>The point is higher responsibility density: fewer handoffs, clearer ownership, better tools, and faster closed loops.</p>

<h2 id="the-smallest-unit-gets-smaller">The Smallest Unit Gets Smaller</h2>

<p>This may become one of the deepest organizational changes created by AI.</p>

<p>The question for a new project used to be:</p>

<p>What roles do we need?
Who handles product?
Who builds?
Who operates?
Who analyzes data?</p>

<p>The future question may be:</p>

<p>Is there one person who can own this loop?
What agents does this person need?
Which steps require human review?
What can be automated?
What result tells us whether this should continue?</p>

<p>If that model works, organizations become lighter.</p>

<p>Many projects can begin as a one-person-company-style unit: one owner, one agent stack, one goal, one measurable result.</p>

<p>If it works, scale it.
If it fails, review quickly and stop.</p>

<h2 id="what-this-means-for-large-companies">What This Means For Large Companies</h2>

<p>For large companies, this does not simply mean fewer roles.</p>

<p>It means more work may be organized around smaller closed-loop units.</p>

<p>Instead of forming a full cross-functional team for every early idea, a company may let one capable owner use agents, tools, and limited expert review to move an opportunity from question to evidence: research, proposal, prototype, early data, and a decision on whether to continue.</p>

<p>That changes collaboration.</p>

<p>More coordination can move from meetings into visible project state: task records, agent logs, review checkpoints, dashboards, and decision notes. The goal is not to remove collaboration, but to reduce the amount of work spent translating context between people.</p>

<p>It also changes management.</p>

<p>Middle management becomes less about passing information and chasing status, and more about defining priorities, assigning resources, designing review systems, and catching risk early. Senior leaders need to know which problems are suitable for small owner-agent units, which require professional teams, and where authority, metrics, and risk boundaries should be set.</p>

<p>The risks are real.</p>

<p>Uneven owner capability becomes more visible. If the owner has weak business judgment, agents help them move faster in the wrong direction. If the owner cannot review quality, agents produce more polished but unreliable output. If many units move quickly without shared standards for records, permissions, data, and review, the company may become locally fast but globally messy.</p>

<p>So the likely structure is not a company with no hierarchy.</p>

<p>It is a flatter organization with stronger operating systems: clearer strategy at the top, managers who design and review execution systems, and smaller project units that can move from idea to evidence with less coordination overhead.</p>

<p>The company will not have no people.</p>

<p>But the smallest execution unit will become smaller.</p>

<p>Hiring will value people who can independently close loops. Management will focus more on goals, state, review, and results, and less on layers of synchronization.</p>

<p>The important question may no longer be how many people a project needs.</p>

<p>It may be:</p>

<p>How far can one capable owner, with a strong agent stack, move a project before a team is needed?</p>]]></content><author><name></name></author><category term="AI" /><category term="Agent" /><category term="Organization" /><summary type="html"><![CDATA[AI does not make one person magically omnipotent. It lowers the friction of moving work forward, making one accountable owner plus an agent stack a new smallest execution unit for many projects.]]></summary></entry><entry><title type="html">Give Your Agent a Phone</title><link href="https://coland-g.github.io/ai/agent/automation/2026/05/26/give-your-agent-a-phone.html" rel="alternate" type="text/html" title="Give Your Agent a Phone" /><published>2026-05-26T00:00:00+08:00</published><updated>2026-05-26T00:00:00+08:00</updated><id>https://coland-g.github.io/ai/agent/automation/2026/05/26/give-your-agent-a-phone</id><content type="html" xml:base="https://coland-g.github.io/ai/agent/automation/2026/05/26/give-your-agent-a-phone.html"><![CDATA[<blockquote>
  <p>Many valuable business workflows are not waiting inside clean APIs. They are trapped inside mobile apps, private channels, and platform interfaces. If agents can operate phones directly, that becomes a new surface for enterprise automation.</p>
</blockquote>

<p><img src="/assets/images/give-your-agent-a-phone-cover.svg" alt="Give Your Agent a Phone" /></p>

<p>We recently built a small but very practical experiment with OpenClaw and iPhone screen mirroring: we let an AI agent operate a phone app as part of a real business workflow.</p>

<p>The first use case was recruiting.</p>

<p>The original goal was straightforward. We had published several job openings and wanted to automate the repetitive parts of early recruiting: reviewing candidate profiles, doing first-pass screening, messaging candidates, asking for resumes, downloading resumes, organizing candidate data, and saving qualified people into a talent database.</p>

<p>At first, browser automation looked like the obvious path. The recruiting platform had a web app. Candidate information was visible in the browser. Messaging could also happen there. In theory, an agent could read the page, compare the candidate against our hiring criteria, and perform the next steps.</p>

<p>In practice, this path was unstable.</p>

<p>Many recruiting platforms are not friendly to AI or RPA-style browser control. They have anti-scraping systems, risk controls, and abnormal behavior detection. For a real business workflow, if automation keeps getting interrupted or creates account risk, it is not a reliable solution.</p>

<p>So we tried a different approach:</p>

<p><strong>If the web page is hard to automate, can we let the agent use the phone instead?</strong></p>

<h2 id="from-browser-automation-to-mobile-screen-mirroring">From browser automation to mobile screen mirroring</h2>

<p>This is where OpenClaw and iPhone screen mirroring become useful.</p>

<p>We turned the phone screen into an interface the agent can observe and operate. The agent can look at the current recruiting app screen, understand the candidate profile and chat context, then click, type, switch views, download files, and record structured information.</p>

<p>The simplest analogy is an intelligent version of a macro tool.</p>

<p>But it is not just a macro tool.</p>

<p>Traditional scripts depend on fixed paths: click this coordinate, type this phrase, save this file. If the UI changes, the candidate replies differently, or the content is not standardized, the workflow breaks.</p>

<p>An agent workflow is closer to a digital coworker that can observe, decide, and leave a trace of what it did. It does not only click. It first reads the current state, then chooses the next action.</p>

<p>In recruiting, that means it can:</p>

<ul>
  <li>Review candidate background, work history, and role preference</li>
  <li>Compare candidates against hiring criteria</li>
  <li>Start or continue early conversations</li>
  <li>Ask candidates for resumes or missing information</li>
  <li>Download and organize resumes</li>
  <li>Save structured candidate data into a table, ATS, or talent database</li>
  <li>Pause uncertain cases for human review</li>
  <li>Summarize daily recruiting progress and follow-up items</li>
</ul>

<p>The value is not that “AI can tap on a phone.”</p>

<p>The value is that a process that used to require a human staring at a mobile app can become an observable, reviewable, structured, and iterative agent workflow.</p>

<h2 id="why-recruiting-is-a-good-starting-point">Why recruiting is a good starting point</h2>

<p>Recruiting is already full of software: ATS tools, resume parsers, candidate databases, and workflow systems.</p>

<p>But in reality, recruiting often does not happen inside one clean, open, standardized system.</p>

<p>Candidate conversations may happen inside mobile apps. Candidate information may be locked behind platform interfaces. Some actions may only be available on mobile. Even if a company has an internal talent database, the first mile of candidate discovery, screening, messaging, and resume collection still requires people to switch across platforms.</p>

<p>That makes recruiting a strong first use case.</p>

<p>It has a few important properties:</p>

<ul>
  <li>High repetition: reviewing profiles, replying to messages, asking for resumes, and making notes happen every day</li>
  <li>Contextual judgment: not every candidate deserves the same next step</li>
  <li>Fragmented information: profiles, chats, resumes, and internal notes live in different places</li>
  <li>Structured output: the final result should enter a resume database, talent pool, CRM, or hiring pipeline</li>
  <li>Human review is possible: uncertain or high-value cases can be escalated</li>
</ul>

<p>These are not unique to recruiting.</p>

<p>They describe many business processes.</p>

<p>The broader idea is this:</p>

<p><strong>Agents can enter the apps and interfaces that previously only humans could operate, then turn repetitive but judgment-heavy workflows into structured business processes.</strong></p>

<h2 id="how-this-differs-from-traditional-rpa">How this differs from traditional RPA</h2>

<p>Some parts look like RPA: the agent operates a UI, clicks buttons, types text, downloads files, and writes data into another system.</p>

<p>But an agent workflow differs from traditional RPA in three important ways.</p>

<p>First, it depends more on context and judgment.</p>

<p>In recruiting, the hard part is not only where to click. It is deciding whether this candidate is worth engaging, how to respond, what information is missing, and when to stop. Sales, support, and operations have the same pattern. The real cost is often not the mechanical action, but the judgment around the action.</p>

<p>Second, it can produce an execution record.</p>

<p>A useful agent workflow should not run silently. It should record what it saw, what it did, why it did it, what was uncertain, and which cases need human attention. That record is how teams review, improve, and turn experience into process assets.</p>

<p>Third, it is designed for human-in-the-loop work.</p>

<p>We do not need the agent to fully own recruiting on day one. A more realistic model is to let agents handle repetitive, low-risk, reviewable steps, while humans keep control over key decisions, exceptions, and high-value candidates.</p>

<p>The best enterprise agents are rarely black boxes. They are workflows with state, review points, escalation paths, and measurable outputs.</p>

<h2 id="what-else-can-be-automated-this-way">What else can be automated this way?</h2>

<p>Recruiting is only the first example.</p>

<p>The same pattern applies to many mobile-first, platform-locked, private-channel, or no-API business processes.</p>

<h3 id="sales-automation">Sales automation</h3>

<p>Many sales leads do not arrive through clean website forms.</p>

<p>They may come from vertical platforms, communities, private messages, comment sections, event lists, partner portals, or mobile-only business systems.</p>

<p>Someone still has to inspect the lead, decide whether it is worth pursuing, send the first message, ask about needs and budget, collect contact details, and log qualified leads into a CRM.</p>

<p>An agent can help with lead filtering, first-touch messaging, qualification, follow-up reminders, and CRM entry.</p>

<p>This maps to sales automation, lead qualification automation, CRM automation, and AI sales assistant workflows.</p>

<h3 id="customer-support-automation">Customer support automation</h3>

<p>Support teams spend a lot of time on repeated questions: order status, refund rules, invoices, product usage, and after-sales progress.</p>

<p>The work often requires switching between a chat window, order backend, policy document, and ticketing system.</p>

<p>An agent can read the customer question, retrieve the relevant context, draft or send a response in low-risk cases, and escalate complaints, payment disputes, emotional messages, or ambiguous policy issues to a human.</p>

<p>This maps to customer support automation, AI support, ticket automation, and after-sales automation.</p>

<h3 id="operations-automation">Operations automation</h3>

<p>Operations teams often live across many platforms: publishing content, reading comments, replying to messages, collecting feedback, checking metrics, taking screenshots, and preparing reports.</p>

<p>If a platform has no API, or if the API does not cover the real workflow, this remains manual.</p>

<p>An agent that can operate platform interfaces can check comments and messages, classify user feedback, identify high-value issues, prepare daily summaries, and escalate anomalies.</p>

<p>This maps to operations automation, content operations automation, private community operations, and user feedback automation.</p>

<h3 id="private-community-and-user-tagging">Private community and user tagging</h3>

<p>In many companies, the most valuable customer signals live in WeChat, enterprise messaging tools, groups, DMs, and private communities.</p>

<p>The information is high-value but unstructured.</p>

<p>An agent can help identify user intent, assign tags, summarize needs, create follow-up reminders, and turn natural conversations into structured user assets, under the right permission and compliance constraints.</p>

<p>This maps to private traffic automation, community operations automation, user tagging automation, and AI operations assistants.</p>

<h3 id="supplier-and-procurement-workflows">Supplier and procurement workflows</h3>

<p>Procurement teams often contact many suppliers to ask for price, delivery time, specs, inventory, and payment terms.</p>

<p>The replies need to be compared and logged. Missing information must be chased. Suspicious prices need attention.</p>

<p>An agent can help initiate requests, collect replies, ask follow-up questions, and structure supplier information and quotes for human review.</p>

<p>This maps to procurement automation, supplier management automation, and quote collection automation.</p>

<h3 id="data-entry-and-mobile-backend-maintenance">Data entry and mobile backend maintenance</h3>

<p>Some systems only have mobile backends, or their web versions are incomplete.</p>

<p>People copy information from chats, screenshots, PDFs, spreadsheets, and platform dashboards into another system.</p>

<p>This work is basic but error-prone.</p>

<p>An agent can extract information, validate fields, enter data, and pause when required fields are missing.</p>

<p>This maps to data entry automation, app automation, mobile workflow automation, and business process automation.</p>

<h2 id="which-workflows-are-good-candidates">Which workflows are good candidates?</h2>

<p>The best starting points usually share a few traits:</p>

<ul>
  <li>People currently handle them by watching a phone, web page, or chat window</li>
  <li>They happen repeatedly and have clear inputs and outputs</li>
  <li>They require some judgment, not just mechanical actions</li>
  <li>Results need to be saved into a table, CRM, ATS, ticketing system, or internal database</li>
  <li>Error cost is controllable and important steps can be reviewed</li>
  <li>The platform has no API, or the API does not cover the real workflow</li>
  <li>The business team already knows the decision criteria, but lacks an automation layer</li>
</ul>

<p>If a workflow matches these conditions, it is a good candidate for agentification.</p>

<p>We do not recommend starting with a huge end-to-end system.</p>

<p>Start with one narrow workflow: resume screening, sales lead logging, support ticket organization, user tagging, supplier quote collection.</p>

<p>Run one complete loop first. Then add better rules, review points, reporting, and integrations.</p>

<h2 id="this-is-not-really-about-tapping-phones">This is not really about tapping phones</h2>

<p>Mobile screen mirroring is only the entry point.</p>

<p>OpenClaw gives agents a way to enter interfaces that are closed, non-standard, or difficult to integrate through APIs. But the real work is not phone control. It is workflow design.</p>

<p>The important questions are:</p>

<ul>
  <li>What state is the task in?</li>
  <li>What did the agent observe?</li>
  <li>What decision did it make?</li>
  <li>What has been saved into the database?</li>
  <li>Which cases need review?</li>
  <li>Which exceptions should pause the workflow?</li>
  <li>Which metrics should become a daily or weekly report?</li>
  <li>Which lessons should become rules for the next run?</li>
</ul>

<p>That is why we call this an agent workflow, not simply mobile automation.</p>

<p>The goal is not to make AI pretend to be a human. The goal is to turn scattered work across apps, web pages, chat tools, and spreadsheets into observable, reviewable, and scalable business workflows.</p>

<p>Recruiting was our first experiment.</p>

<p>Sales, customer support, operations, private community management, procurement, and data entry are all natural next candidates.</p>

<p>If your company has work that is still trapped inside mobile apps, closed platforms, chat windows, or systems without useful APIs, this may be a practical place to start.</p>

<p>Start with one real workflow.</p>

<p>Let the agent run one measurable loop.</p>

<p>Then decide whether it deserves to become part of the company’s operating system.</p>]]></content><author><name></name></author><category term="AI" /><category term="Agent" /><category term="Automation" /><summary type="html"><![CDATA[Many valuable business workflows are not waiting inside clean APIs. They are trapped inside mobile apps, private channels, and platform interfaces. If agents can operate phones directly, that becomes a new surface for enterprise automation.]]></summary></entry><entry><title type="html">AI Makes the One-Person Company Imaginative Again</title><link href="https://coland-g.github.io/ai/agent/opc/2026/05/14/one-person-company-ai-agents.html" rel="alternate" type="text/html" title="AI Makes the One-Person Company Imaginative Again" /><published>2026-05-14T00:00:00+08:00</published><updated>2026-05-14T00:00:00+08:00</updated><id>https://coland-g.github.io/ai/agent/opc/2026/05/14/one-person-company-ai-agents</id><content type="html" xml:base="https://coland-g.github.io/ai/agent/opc/2026/05/14/one-person-company-ai-agents.html"><![CDATA[<blockquote>
  <p>The real value of a one-person company is not that one person ships more things alone. It is that AI and agents make it possible to redesign how one person turns ideas into real work, decisions, workflows, and learning loops.</p>
</blockquote>

<p><img src="/assets/images/one-person-company-ai-agents-cover.png" alt="One-person company with AI agents" /></p>

<p>The idea of the OPC — the one-person company — is being discussed more often now.</p>

<p>There are two very different reactions to it.</p>

<p>One side is optimistic: AI and agents may give individual founders the kind of execution power that previously required a small team.</p>

<p>The other side is skeptical: maybe the one-person company is just a well-packaged concept that sounds exciting, but falls apart when it has to face product work, operations, growth, delivery, and actual business results.</p>

<p>I do not want to write this as a conceptual explainer, and I do not want to simply pick a side.</p>

<p>I want to talk about my own choice: why I am choosing this way of building today, why I have always wanted to turn the ideas in my head into real things, what AI and agents have changed, and what I hope to learn from this way of running a one-person company.</p>

<h2 id="i-have-always-had-things-i-wanted-to-build">I have always had things I wanted to build</h2>

<p>I have wanted to build my own company for a long time.</p>

<p>Ideas keep appearing in my head: directions I want to explore, problems I want to solve, product shapes I want to try, tools I think should exist, or simply moments where I feel that “this should be done better.”</p>

<p>Most of them are not complete business plans at first. They are just scenes, fragments, product instincts, or unresolved problems.</p>

<p>But they stay in my head. The more I think about them, the more I want to build them and see whether they can work.</p>

<p>In the past, I kept trying different kinds of projects: CcView for low-code visual dashboards, CcBailu as a component library, CcServer as a backend system, and CcClip as a video editing tool.</p>

<p>Behind these projects was the same impulse: I would see a direction, feel that it was worth trying, and want to make it real.</p>

<p>But once I actually started building, I quickly ran into the same problem: the hardest part of solo building was not the lack of ideas. It was that every part of the execution chain eventually came back to me.</p>

<p>Product, engineering, testing, deployment, bugs, operations, data, growth — everything had to be handled. Any small problem could pull me back into repeated low-level work.</p>

<p>At that time, I was basically using personal effort to chase the speed of a small team. The only way to move faster was to work more. The rhythm could easily become inverted: work until sleep, wake up, keep working, and sometimes not even know whether I had just fallen asleep or had slept for a long time.</p>

<p>Looking back, that was not very efficient.</p>

<p>More importantly, it slowly drained the passion I had for the thing itself.</p>

<p>A lot of time went into small, basic, detailed problems: tracing a bug, locating an exception, fixing an environment issue, polishing a tiny interaction, or dealing with a deployment detail. The time actually spent pushing the larger idea or the main product direction forward was often very limited.</p>

<p>You could even say that 80% of the time was spent on foundational work. The time used for learning, growth, and understanding something new was much smaller. But in the actual process, those small details could trap you for a long time and pull you back into inefficient tasks again and again.</p>

<p>That is why I eventually felt that in a pure tool-building startup, individual technical skill does not create an absolute advantage over a mature small team. No matter how strong one person is, it is difficult to use stamina and familiarity to compete with a team that has clear division of labor.</p>

<h2 id="why-today-feels-different">Why today feels different</h2>

<p>If I look at the same problem today, my judgment is different.</p>

<p>If the current level of AI tools and agent capabilities had existed back then, I probably could have built much more in the same amount of time. Not just building the same product faster, but trying more directions, running more iterations, and testing more product shapes.</p>

<p>That is why the one-person company still attracts me today.</p>

<p>Compared with the old process of turning ideas into products — a process I often disliked because it was full of draining execution details — AI and agents finally give me a method I genuinely like: break ideas down, move them forward, verify them, and deliver them while spending more energy on the work I actually care about.</p>

<p>In the past few years, while working in an AI company, I had already used AI to solve many small tasks. But those uses were scattered: use AI to assist one task, organize one piece of content, or generate one first-pass solution.</p>

<p>Now agents make it possible to connect those scattered capabilities into a more complete workflow.</p>

<p>That matters to me.</p>

<p>It does not mean AI can already run a company for you. It also does not mean humans stop mattering. The opposite is true: human judgment becomes more important — choosing direction, deciding what is worth doing, reviewing results, knowing where automation is acceptable, and knowing where human review must stay in the loop.</p>

<p>I now see the one-person company as a constraint: if I choose to build this way, I should not always think about solving problems by hiring more people.</p>

<p>Instead, I should first ask: can AI plus myself produce the output of multiple roles? Can work that used to require several people be redesigned into a system where I make judgments, AI executes, and workflows handle the handoff?</p>

<p>Of course I want to try that.</p>

<p>Not because one person suddenly becomes stronger than a team, but because AI expands the radius of experimentation for one person. It also makes building the things I care about feel more comfortable and more sustainable.</p>

<h2 id="what-i-am-building-now">What I am building now</h2>

<p>For this company, the core principle is simple: use AI well, and use it often.</p>

<p>I currently have around a dozen agents running. They are not just names placed on a board. They are divided by role, each with its own tasks, inputs, outputs, and collaboration boundaries.</p>

<p>When I have an idea, I can first send it to an agent responsible for early-stage organization. It helps with initial research, planning, decomposition, and records the project into Feishu documents or tables. From there, the project can continue flowing through different roles:</p>

<ul>
  <li>market research agents for industry, competitor, and user research;</li>
  <li>product design agents for turning requirements into product plans;</li>
  <li>development agents for implementation;</li>
  <li>testing agents for validation;</li>
  <li>data instrumentation and monitoring agents for metrics;</li>
  <li>operations and growth agents for launch, campaigns, and growth strategy;</li>
  <li>daily and weekly report agents for continuous review.</li>
</ul>

<p>This is the positive agent workflow I am currently shaping.</p>

<p>It does not mean I have completely abandoned the familiar product-engineering-testing-operations process. In many ways, the flow is still similar: ideas need research, requirements need design, products need development, results need testing, data needs observation, and operations need to continue.</p>

<p>The difference is that many actions that used to require my own hands can now be assigned to different agents.</p>

<p>I am still present in all the key positions.</p>

<p>But the center of my work changes:</p>

<ul>
  <li>I decide direction;</li>
  <li>I judge what is worth doing;</li>
  <li>I review plans;</li>
  <li>I review code;</li>
  <li>I review the output of each digital worker;</li>
  <li>I define input and output standards;</li>
  <li>I design the workflow;</li>
  <li>I still make subjective decisions about logo, site tone, and visual style.</li>
</ul>

<p>So this is not me disappearing from the roles.</p>

<p>It is me still standing in the key roles, while no longer spending most of my time on the mechanical actions inside each role.</p>

<p>In the past, I was using one person’s execution to chase a small team.</p>

<p>Now I want to use one person’s judgment to organize the execution power of a group of agents.</p>

<h2 id="the-most-interesting-part-is-that-the-working-model-can-keep-evolving">The most interesting part is that the working model can keep evolving</h2>

<p>The workflow I am running now still grows out of a familiar product and engineering process.</p>

<p>That is natural. I understand product, engineering, testing, operations, and growth, so the first step is to translate that familiar process into agent roles.</p>

<p>This step matters.</p>

<p>It is not the destination, but it is the starting point. Only after running a familiar workflow can I learn which parts can truly be given to AI, which parts require human judgment, where the workflow gets stuck, and which parts can be abstracted into tools.</p>

<p>But I increasingly feel that AI-to-AI collaboration does not have to stay inside the old organizational structure forever.</p>

<p>In the past, we assumed a product should move through a complete chain: requirement, research, design, development, testing, launch, operations, and data review. That chain is valuable, but it was also shaped by the way human teams were organized.</p>

<p>Once the executors become agents, some things that used to be unrealistic may become possible.</p>

<p>For example, I am thinking about a faster system: compressing the chain from demand discovery to implementation to delivery into less than one hour.</p>

<p>This does not have to be the full traditional product-engineering-testing rhythm. It could focus on a specific professional problem: discover a need, decompose it, solve it, and deliver something useful quickly.</p>

<p>This is still being designed, but I am excited about it.</p>

<p>Because it reminds me that the interesting part of OPC is not combining a few capabilities, and not simply saying “I have an agent workflow.”</p>

<p>The interesting part is that I can keep iterating my tools, my working method, and the shape of the organization itself.</p>

<p>At first, I can translate a familiar development process into agent roles. Later, I may discover new ways for agents to collaborate, new ways for needs to be discovered and delivered, and new organizational forms that do not need to look exactly like a traditional company.</p>

<p>That is what excites me most: I am not only building a product. I am continuously shaping how I work.</p>

<h2 id="i-do-not-want-to-measure-opc-by-product-count">I do not want to measure OPC by product count</h2>

<p>There are also many reasonable doubts about OPC. Some people think it is old wine in a new bottle. Some think one-person companies will mostly produce rough products. Some think AI-generated products will become a pile of junk apps.</p>

<p>These doubts are not meaningless.</p>

<p>If OPC is understood as “one person using AI to maximize output volume,” then it can easily become a low-quality production contest: three websites today, five apps tomorrow, another direction the day after. It looks busy and efficient, but may leave behind no real product, organizational capability, or user value.</p>

<p>So I do not want to measure a one-person company by “how many products it ships per month.”</p>

<p>The more important questions are:</p>

<ul>
  <li>How many key decisions did I make today?</li>
  <li>Were those decisions recorded, verified, and reviewed?</li>
  <li>Is my workflow smoother than yesterday?</li>
  <li>Which repeated tasks became systematized?</li>
  <li>Which painful collaboration patterns were removed?</li>
  <li>Which agents or tools became part of organizational capability, not just one-off toys?</li>
</ul>

<p>As the organization and tools mature, output speed will certainly increase.</p>

<p>But that speed should not only mean “more things shipped.” It should mean that in the same day, I can make more effective judgments, test more hypotheses, move more real problems forward, and preserve those processes for the next cycle.</p>

<p>I care more about effective decision density.</p>

<p>How many decisions that truly move things forward did this organization make in one day? Did those decisions have evidence? Were they executed? Were they verified? Did they become input for the next decision?</p>

<p>Recently, when observing Peter Steinberger, the author of OpenClaw, I have felt this gap very clearly. The density at which he processes GitHub issues, pull requests, iterations, and product decisions is far beyond what I can currently match.</p>

<p>That is not only about working harder.</p>

<p>There must be a supporting system behind it: how tasks enter, how priorities are judged, how agents participate, how code is reviewed, how state is synchronized, and how user feedback becomes action.</p>

<p>That is the capability I want to build.</p>

<h2 id="what-i-will-validate-next">What I will validate next</h2>

<p>In the end, all of this is still being explored.</p>

<p>One track is the positive agent workflow that translates an existing product-development process into agent roles. The other is a faster way to discover, implement, and deliver needs.</p>

<p>I cannot say yet that either one is definitely correct.</p>

<p>The next task is to validate them through real projects, real tasks, and real product requirements.</p>

<p>Which workflows truly improve efficiency?</p>

<p>Which agent collaboration patterns only look good on paper?</p>

<p>Where must human judgment stay strongly in the loop?</p>

<p>Which parts can become reusable tools, templates, scripts, workflows, or even open-source contributions?</p>

<p>These answers can only come from real work.</p>

<p>So I will continue to tune this system. If something becomes reusable, open-sourceable, or useful for others, I will share it.</p>

<p>I also hope future writing can become more practical. The previous articles have already covered much of my broader thinking about AI’s development, its current impact, my current state, my choice, and my personal inclinations. The high-level conceptual discussion is mostly done for now.</p>

<p>Future updates may be less frequent.</p>

<p>But they will be more concrete: observations from real projects, mistakes from real tasks, lessons from agent collaboration, methods from workflow design, and new understanding formed while building this company.</p>

<p>I am less interested in making the concept sound bigger.</p>

<p>I am more interested in putting it into real work and seeing how far it can actually go.</p>

<p>If it works, I will share the process, the methods, and the reusable pieces.</p>

<p>That is what I want most from this one-person company: not a beautiful concept, but a working method that can truly help me turn ideas into reality.</p>]]></content><author><name></name></author><category term="AI" /><category term="Agent" /><category term="OPC" /><summary type="html"><![CDATA[The real value of a one-person company is not that one person ships more things alone. It is that AI and agents make it possible to redesign how one person turns ideas into real work, decisions, workflows, and learning loops.]]></summary></entry><entry><title type="html">In the AI Era, Your Real Asset Is Not Better Answers, but a Library of Solved Problems</title><link href="https://coland-g.github.io/ai/learning/personal-growth/2026/05/11/ai-era-personal-growth.html" rel="alternate" type="text/html" title="In the AI Era, Your Real Asset Is Not Better Answers, but a Library of Solved Problems" /><published>2026-05-11T00:00:00+08:00</published><updated>2026-05-11T00:00:00+08:00</updated><id>https://coland-g.github.io/ai/learning/personal-growth/2026/05/11/ai-era-personal-growth</id><content type="html" xml:base="https://coland-g.github.io/ai/learning/personal-growth/2026/05/11/ai-era-personal-growth.html"><![CDATA[<blockquote>
  <p>AI makes answers cheap. Personal growth does not come from receiving better answers. It comes from turning real problems into experiments, results, reflection, and reusable know-how.</p>
</blockquote>

<p><img src="/assets/images/9f76d414-c61e-4999-bb37-3b4e5c943b14.png" alt="From answers to know-how" /></p>

<p>AI is changing the environment for learning.</p>

<p>In the past, when we did not understand something, we usually learned through work: a project, a difficult task, a leader, a mentor, a colleague, or a long trail of Google searches. We collected clues, compared different answers, tried something, failed, asked again, and slowly built experience.</p>

<p>Today, a large part of that process can be compressed into one prompt.</p>

<p>ChatGPT, Claude, Gemini, and agentic tools can explain concepts, summarize documents, write code, compare options, draft strategies, and search across large amounts of information. In practice, it feels as if everyone can have a very strong mentor sitting next to them: patient, fast, widely read, and available at any time.</p>

<p>That is obviously powerful.</p>

<p>But it also raises a harder question:</p>

<p><strong>If answers become this easy to obtain, how should individuals grow?</strong></p>

<p>This reminds me of an early work experience.</p>

<p>When I first started working, I had a very strong leader. His coding ability was excellent. When I ran into a problem and asked him for help, he could often identify the issue quickly and even write the code for me.</p>

<p>In the short term, that was great. The problem was solved. The project moved forward. I avoided many mistakes.</p>

<p>But the important part of the story is what happened next: I would roll back everything he wrote, keep his thinking as a reference, and implement the solution again by myself. Even if he had already given me the answer, I still needed to do it with my own hands.</p>

<p>Because if someone simply hands me the final answer every time, and I do not go through the process again, I do not really gain much.</p>

<p>I need to experience the questions myself:</p>

<ul>
  <li>Why did this fail?</li>
  <li>What alternative solutions exist?</li>
  <li>Why does this solution work here?</li>
  <li>Under what conditions would it stop working?</li>
  <li>How should I judge a similar problem next time?</li>
</ul>

<p>A problem being solved does not mean the experience has become mine. It starts becoming mine only after I reconstruct it myself.</p>

<p>AI creates the same risk, only at a much larger scale.</p>

<p>AI can be stronger, faster, and more patient than that leader. It will not get annoyed by basic questions. It will not be too busy to respond. But if we only use AI as an answer machine, we may become better at receiving outputs while becoming worse at building the experience that makes those outputs useful.</p>

<h2 id="what-we-actually-accumulate-is-not-knowledge-points-but-problem-solving-experience">What We Actually Accumulate Is Not Knowledge Points, but Problem-Solving Experience</h2>

<p>Looking back at years of work, I increasingly believe that a person’s value is not mainly about how many facts they know.</p>

<p>Knowing a tool, a framework, or an industry term is useful. But the deeper value comes from something more contextual:</p>

<ul>
  <li>What real problems have I solved?</li>
  <li>What constraints and variables existed at the time?</li>
  <li>How did I define the core problem?</li>
  <li>What assumptions did I make?</li>
  <li>What solutions did I try?</li>
  <li>What worked, what failed, and why?</li>
  <li>What judgment did I form after seeing the result?</li>
</ul>

<p>This is what I mean by know-how.</p>

<p>It is not a paragraph that can be copied and pasted. It is not a capability automatically gained after reading an article. It is closer to a system for solving new problems by drawing on previous cases, variables, failures, and results.</p>

<p>The same question can have very different answers depending on the company, market cycle, team capability, budget, timeline, user expectations, and risk tolerance.</p>

<p>Experienced people are valuable because they do not only know an answer. They know the conditions behind the answer. They know when it applies, when it breaks, which variables matter, and which small-looking details can change the outcome.</p>

<p>That is difficult to get from search alone.</p>

<p>It is also difficult to get from AI alone.</p>

<p>AI can give you a strong average answer. But your own know-how has to grow through real problems, real attempts, and real results.</p>

<h2 id="when-answers-become-cheap-experience-becomes-more-visible">When Answers Become Cheap, Experience Becomes More Visible</h2>

<p>Google made information cheap. AI is making answers cheap.</p>

<p>That means many old advantages will be compressed: knowing where to find information, being able to write a basic draft, producing boilerplate code, or summarizing a topic quickly.</p>

<p>Microsoft’s 2025 Work Trend Index uses the phrase “intelligence on tap.” The idea is that intelligence is becoming abundant, scalable, and available on demand. The same report argues that more people will need to become “agent bosses”: people who build, delegate to, and manage agents to amplify their own impact.</p>

<p>This matters because when intelligence becomes infrastructure, human differences do not disappear. They move to another layer.</p>

<p>In the past, the difference might have been:</p>

<ul>
  <li>Who knows more?</li>
  <li>Who searches faster?</li>
  <li>Who can write the first version?</li>
</ul>

<p>In the AI era, the difference is more likely to be:</p>

<ul>
  <li>Who can define the right problem?</li>
  <li>Who can break it into testable assumptions?</li>
  <li>Who knows what counts as a real result?</li>
  <li>Who can judge whether an AI answer fits the current context?</li>
  <li>Who can turn AI output into action?</li>
  <li>Who can learn from the outcome and update their judgment?</li>
</ul>

<p>Workday’s 2025 global research report makes a similar point from another angle. It reports that 93% of active AI users agree that AI lets them focus more on higher-level responsibilities such as strategy and problem solving. It also reports that 83% of respondents believe AI will elevate the importance of uniquely human skills and enhance human creativity.</p>

<p>In other words, AI does not remove the need for growth. It pushes growth to a higher level.</p>

<p>If AI can draft the first version of a strategy, you need to become better at judging whether the strategy is good.</p>

<p>If AI can generate code, you need to understand architecture, boundaries, testing, maintenance cost, and risk.</p>

<p>If AI can summarize materials, you need to know which materials matter and which are noise.</p>

<p>Once low-level answers become cheap, the scarce capability is the ability to place answers inside real problems and get results.</p>

<h2 id="we-need-a-better-way-to-manage-knowledge-after-answers-become-cheap">We Need a Better Way to Manage Knowledge After Answers Become Cheap</h2>

<p>This is why I have become more interested in personal growth tools.</p>

<p>We already have many ways to record information: Markdown, Word documents, spreadsheets, Notion, Feishu docs, and personal knowledge bases. They are useful, but simply recording what we have read is not enough.</p>

<p>A knowledge base can easily become a warehouse.</p>

<p>Today we save an article. Tomorrow we bookmark a link. The day after that we write down a thought. The amount of content increases, but very little of it enters action, decision-making, or review. In the end, it becomes a list of things we once found interesting, not a system that helps us grow.</p>

<p>A more valuable record should not only ask:</p>

<p><strong>What does this article say?</strong></p>

<p>It should ask:</p>

<p><strong>What judgment did this change? What type of problem can it help me solve? Did I use it in a real action? What was the result?</strong></p>

<p>For example, if I read an article about AI agents, it should not only become a saved link. It can become a capability record:</p>

<ul>
  <li>What problem does it relate to? For example: how can an individual use agents to increase work output?</li>
  <li>What assumption does it suggest? For example: more workers may need to manage groups of agents.</li>
  <li>How will I test it? For example: use agents to complete one research, writing, and publishing workflow.</li>
  <li>What result did I get? For example: how much time was saved, whether quality improved, and where human intervention was still required.</li>
  <li>Where can this experience transfer? For example: content production, product research, coding, customer support, or internal operations.</li>
</ul>

<p>At that point, the record is no longer just knowledge storage. It becomes a capability asset.</p>

<p>I increasingly think the next personal growth system should be a capability library, not only a knowledge base.</p>

<p>A knowledge base answers: <strong>what do I know?</strong></p>

<p>A capability library answers: <strong>what have I solved?</strong></p>

<h2 id="a-capability-library-should-record-problems-variables-assumptions-solutions-results-and-review">A Capability Library Should Record Problems, Variables, Assumptions, Solutions, Results, and Review</h2>

<p>If we want to turn know-how into an asset, the record needs several dimensions.</p>

<p>First: the problem.</p>

<p>Do not record “I learned about AI agents” in a vague way. Record the actual problem: what was I trying to solve? Why did it matter? Was it a product, engineering, marketing, operations, management, business, creative, or personal growth problem?</p>

<p>Second: the variables.</p>

<p>No problem exists in isolation. Budget, time, team capability, market stage, technology maturity, user awareness, and resource constraints all affect the solution. Experience without variables easily becomes empty advice.</p>

<p>Third: the assumption.</p>

<p>Why did I think this approach might work? What judgment was behind it? If the assumption was wrong, how would the result change?</p>

<p>Fourth: the solution.</p>

<p>What exactly did I do? What tools did I use? What steps did I take? Which part did AI handle, and which part did I keep for human judgment?</p>

<p>Fifth: the result.</p>

<p>“Feels good” is not enough. The result should have some evidence: completion, time saved, conversion, quality, adoption, feedback, or failure signals.</p>

<p>Sixth: the review.</p>

<p>What did I learn? What would I do differently next time? Which parts can transfer to other contexts, and which only worked under this specific condition?</p>

<p>After enough records like this, a person gradually builds a map of their own capabilities.</p>

<p>For example, if I have never solved problems around user growth, pricing, retention, prioritization, or cross-functional coordination, then my product capability in those areas should not be rated very high. Not because I have read too few articles, but because I do not yet have enough proven paths.</p>

<p>But if I have handled many engineering problems around architecture, performance, deployment, collaboration, code quality, and automation, and each one has results and review, then that part of my capability asset is thicker.</p>

<p>This is more honest than a resume label.</p>

<p>It does not say “I am a product manager” or “I am an engineer.” It asks: what problems have I actually solved, how complex were they, and can the experience transfer to new situations?</p>

<h2 id="when-work-does-not-give-you-enough-problems-learn-to-create-your-own">When Work Does Not Give You Enough Problems, Learn to Create Your Own</h2>

<p>Traditionally, we relied on work to give us problems.</p>

<p>A company has projects. A leader assigns tasks. Customers create requirements. Teams run into conflicts. We grow inside those pressures because work gives us problems, constraints, collaborators, and feedback.</p>

<p>But work does not always give us the best growth problems.</p>

<p>Sometimes the problems are too narrow. Sometimes they are too repetitive. Sometimes the organization does not encourage experimentation. Sometimes we want to build cross-industry or cross-domain experience, but our current role does not provide those opportunities.</p>

<p>AI changes this.</p>

<p>We can use AI to create more problems for ourselves. We can use it to explore a field, break down assumptions, gather materials, design small experiments, generate alternative solutions, simulate opposing views, and help us review results.</p>

<p>The best use of AI is not only:</p>

<p><strong>Please finish this task for me.</strong></p>

<p>A better use is:</p>

<ul>
  <li>Help me find the problem.</li>
  <li>Help me break it down.</li>
  <li>Help me gather materials.</li>
  <li>Help me design an experiment.</li>
  <li>Help me generate multiple solutions.</li>
  <li>Help me review the result.</li>
  <li>Help me turn this experience into a capability record.</li>
</ul>

<p>But the most important step cannot be skipped: you still need to try something and get a result.</p>

<p>Without action and result, AI gives you only an answer.</p>

<p>With action and result, AI can help turn the answer into experience.</p>

<p>This may be one of the most important directions for personal growth in the next stage: move from passively receiving tasks to actively creating problems; from waiting for work to provide experience to designing your own experiments; from recording knowledge to accumulating verifiable know-how.</p>

<h2 id="the-valuable-person-is-the-one-with-cross-context-know-how">The Valuable Person Is the One With Cross-Context Know-How</h2>

<p>So if the question is how individuals should develop as AI and agents advance, my answer is not “learn one specific tool” or “memorize a set of prompt templates.”</p>

<p>Tools will change. Models will change. Agent interfaces will change.</p>

<p>The deeper direction is this:</p>

<p><strong>Use AI to define problems faster, form assumptions faster, run experiments faster, get results faster, and then turn those results into your own capability library.</strong></p>

<p>The more valuable person is not necessarily the one who asks AI the most questions. It is the one who uses AI to accumulate real experience faster.</p>

<p>That person will have many cases in hand: under different market conditions, with different resource constraints, collaborating with different people, facing different variables, they tried different solutions, got different results, and formed their own judgments.</p>

<p>Together, those cases become know-how.</p>

<p>AI can help us approach answers faster.</p>

<p>But growth is not the answer itself.</p>

<p>Growth is going through a problem, getting the result, seeing the variables clearly, reviewing both failure and success, and then facing the next problem with better judgment.</p>

<p>That ability may become one of the most important personal assets in the AI era.</p>

<h2 id="references">References</h2>

<ul>
  <li>Workday, <em>Elevating Human Potential: The AI Skills Revolution</em> / “New Global Research from Workday Reveals AI Will Ignite a Human Skills Revolution”: https://newsroom.workday.com/2025-01-14-New-Global-Research-from-Workday-Reveals-AI-Will-Ignite-a-Human-Skills-Revolution</li>
  <li>Microsoft, <em>The 2025 Annual Work Trend Index: The Frontier Firm is born</em>: https://blogs.microsoft.com/blog/2025/04/23/the-2025-annual-work-trend-index-the-frontier-firm-is-born/</li>
</ul>]]></content><author><name></name></author><category term="AI" /><category term="Learning" /><category term="Personal-Growth" /><summary type="html"><![CDATA[AI makes answers cheap. Personal growth does not come from receiving better answers. It comes from turning real problems into experiments, results, reflection, and reusable know-how.]]></summary></entry><entry><title type="html">Digital Employees Are Starting to Work, but the Hard Part Is Not Replacing People</title><link href="https://coland-g.github.io/ai/agent/digital-workers/2026/05/08/digital-employees.html" rel="alternate" type="text/html" title="Digital Employees Are Starting to Work, but the Hard Part Is Not Replacing People" /><published>2026-05-08T00:00:00+08:00</published><updated>2026-05-08T00:00:00+08:00</updated><id>https://coland-g.github.io/ai/agent/digital-workers/2026/05/08/digital-employees</id><content type="html" xml:base="https://coland-g.github.io/ai/agent/digital-workers/2026/05/08/digital-employees.html"><![CDATA[<blockquote>
  <p>Digital employees are moving from marketing language into early production use. But the real challenge is not whether AI can replace a job title. The challenge is whether AI can receive tasks, keep state, deliver outcomes, stay auditable, and collaborate inside a real organization.</p>
</blockquote>

<p><img src="/assets/images/digital-employees-cover.png" alt="cover" /></p>

<p>“Digital employee” is becoming a popular phrase again.</p>

<p>A few years ago, it usually appeared in the context of RPA, customer-service bots, or virtual avatars: a bot that filled in forms, an online support widget, or a digital human that could read scripts or appear in livestreams.</p>

<p>Today the same phrase is attached to a different set of ideas: AI employee, digital worker, AI agent, AI teammate.</p>

<p>The words sound similar, but the direction has changed.</p>

<p>The older version of a digital employee automated an action. The new version wants to own a more complete work outcome: finding leads, writing emails, making calls, resolving customer issues, searching legal documents, fixing code, organizing company knowledge, or pushing a business process forward.</p>

<p>After looking at a group of overseas and Chinese companies in this space, my current view is this:</p>

<p><strong>Digital employees have moved from concept marketing into early production deployment, but they are not mature enough to fully replace complete roles. Overseas companies are more aggressively selling “hireable vertical agents.” In China, the mainstream form is still RPA + LLM, customer service and marketing automation, office automation, enterprise knowledge QA, and low-code agent platforms.</strong></p>

<p>The more interesting question is not “will AI replace this job?”</p>

<p>It is that software delivery itself is changing: from selling tools to selling work, from charging by seats to charging by tasks or outcomes, and from humans operating software to software entering the division of labor inside organizations.</p>

<h2 id="overseas-digital-employees-are-being-packaged-as-hireable-roles">Overseas: Digital Employees Are Being Packaged as Hireable Roles</h2>

<p>A common pattern among overseas AI employee companies is that they do not want to describe themselves as “tools.”</p>

<p>11x is explicit: it says it sells work, not software. Its digital worker Alice is an AI SDR that handles prospect research, multichannel outreach, and personalization. Its phone agent handles inbound lead qualification and outbound calling. 11x announced a $24 million Series A led by Benchmark in 2024.</p>

<p>Artisan is even more direct. It calls its products AI employees. Its first employee, Ava, is an AI BDR that finds leads, researches them, writes and sends emails, and books meetings. Artisan announced a $25 million Series A in 2025 and became known for the “Stop hiring humans” billboard. But the company’s own explanation is more nuanced: the target is not every part of human work, but the most repetitive and draining parts of outbound sales.</p>

<p>Sierra is focused on customer-service AI agents. The important part is not only the product, but also the pricing model. Sierra openly discusses outcome-based pricing: customers pay when the agent completes a valuable outcome, such as resolving a conversation, saving a cancellation, or completing an upsell. That pushes the agent away from being “another software seat” and toward being a measurable business unit.</p>

<p>Decagon is also in customer experience. It announced $250 million in funding at a $4.5 billion valuation, with customers including Avis Budget Group, Block, and Deutsche Telekom. Its language is not traditional chatbot automation, but “concierge customer experience”: more proactive, more personalized, and more focused on resolution.</p>

<p>Harvey represents the legal vertical. It announced a $300 million Series E at a $5 billion valuation. Legal work is naturally suited for vertical agents: dense text, high search requirements, professional standards, compliance constraints, and expensive expert time. Harvey is not a generic assistant. It embeds AI into real workflows for law firms and enterprise legal teams.</p>

<p>Cognition’s Devin is another important example. It presents Devin as an AI software engineer that can use a shell, code editor, and browser in a sandboxed environment, work on GitHub issues, debug, deploy, and learn unfamiliar technologies. The core question here is not whether AI can write code. It is whether it can reliably and audibly participate in the software engineering workflow.</p>

<p>Glean, Microsoft Copilot Studio, Salesforce Agentforce, and Moveworks represent another path. Instead of defining a single AI job title first, they give enterprises a platform to create and manage agents inside their own knowledge, permissions, workflows, CRM, IT, HR, and service-desk systems. Glean announced a $150 million Series F at a $7.2 billion valuation in 2025, and said Glean Agents already powers more than 100 million annualized agent actions. Microsoft describes agents as the new apps for an AI-powered world. Salesforce Agentforce describes its platform as a way to deploy digital labor safely for customers, suppliers, and employees.</p>

<p>So the overseas market can be roughly divided into two paths.</p>

<p>The first path is <strong>role-based digital employees</strong>. These companies start from a clear job category: SDR, BDR, customer support, legal assistant, software engineer. Their pitch is not “we help you become more efficient,” but “you can hire this AI to do this work.”</p>

<p>The second path is <strong>enterprise agent platforms</strong>. These companies do not necessarily promise to replace a specific role. Instead, they help companies build agents within their own data, permissions, systems, and workflows. Their value is governance, integration, security, and lifecycle management.</p>

<p>Both paths matter. The first feels more like a new species. The second is easier to adopt inside large enterprises.</p>

<h2 id="china-more-often-an-upgrade-of-existing-enterprise-software">China: More Often an Upgrade of Existing Enterprise Software</h2>

<p>The Chinese market also talks about digital employees, but the implementation path is more pragmatic.</p>

<p>The mainstream form today is not “one AI employee owns a complete role.” It is usually a combination of several capabilities:</p>

<ul>
  <li><strong>RPA + LLM:</strong> making system operations, data entry, approval flows, finance, HR, reconciliation, and reporting more intelligent.</li>
  <li><strong>Customer service, marketing, and CRM agents:</strong> automating support, agent assist, outbound calls, quality inspection, and sales follow-up.</li>
  <li><strong>Office collaboration AI:</strong> improving documents, meetings, approvals, knowledge bases, and IM-based workflows.</li>
  <li><strong>Enterprise knowledge QA and agent platforms:</strong> letting companies build agents on top of their own data and tools.</li>
  <li><strong>Digital humans and avatars:</strong> useful for interaction, voice, and video, but not necessarily responsible for process execution.</li>
</ul>

<p>Baidu Qianfan, Alibaba Cloud Bailian, Tencent Cloud ADP, and Huawei Cloud Pangu/MaaS are infrastructure-style players. They provide models, RAG, MCP, workflows, multi-model management, and low-code agent development platforms. Their platform capabilities are strong, but enterprises still need to define the actual workflow and business scenario.</p>

<p>DingTalk, Feishu, and Coze represent the office-collaboration entry point. They are closer to where work actually happens: documents, meetings, approvals, IM, knowledge bases, and project collaboration. But office AI has a key limitation: it can be useful without being accountable. If an agent only answers questions, summarizes documents, or generates content, it is still an assistant. It starts to resemble an employee only when it can receive tasks, keep state, move a process forward, accept review, and leave records.</p>

<p>Laiye, Cyclone Robotics, Encoo, and AI-Indeed represent the RPA and intelligent automation path. This is probably the most mature landing base for “digital employees” in China, because many enterprise tasks are indeed cross-system operations: copying, pasting, checking, entering, reviewing, and moving data through processes. The challenge for RPA companies is that they understand processes, but they may be squeezed by cloud model platforms and office entry points. The future competition is not only who can click buttons. It is who can understand context, plan steps, handle exceptions, and deliver results back to the business.</p>

<p>Udesk, Ronglian Cloud, and SalesEasy are examples of customer-service, marketing, and CRM vendors. This may be the clearest commercialization path because the metrics are concrete: response time, conversion rate, quality score, complaint rate, follow-up rate, and cost reduction.</p>

<p>So if the question is whether China’s digital employee market is still mainly RPA + LLM, customer service, marketing, and office automation, my answer is yes.</p>

<p>More precisely, many Chinese “digital employee” products today are not yet a new organizational form. They are existing enterprise software upgraded and repackaged for the LLM era. That is valuable, but it is still one layer away from a real agent company.</p>

<h2 id="maturity-from-answering-to-delivering-to-collaborating">Maturity: From Answering, to Delivering, to Collaborating</h2>

<p>I find it useful to divide digital employees into four stages.</p>

<h3 id="1-rpa-software-clicks-buttons">1. RPA: Software Clicks Buttons</h3>

<p>This stage solves repetitive operations: logging into systems, copying data, filling forms, downloading reports, reconciling data, and sending notifications.</p>

<p>It does not need deep business understanding. If the process is stable, it can save labor.</p>

<h3 id="2-ai-assistant-software-helps-people-think-and-create">2. AI Assistant: Software Helps People Think and Create</h3>

<p>This stage solves cognitive assistance: writing copy, summarizing meetings, searching knowledge bases, drafting emails, and answering questions.</p>

<p>It clearly improves individual productivity, but in most cases it does not independently own an outcome.</p>

<h3 id="3-role-agent-software-owns-part-of-a-job">3. Role Agent: Software Owns Part of a Job</h3>

<p>This is where today’s AI employee companies are heading.</p>

<p>AI SDRs, AI BDRs, AI customer-service agents, AI legal assistants, and AI software engineers all belong here.</p>

<p>They no longer merely generate content. They continuously execute a set of tasks around a role-level goal.</p>

<h3 id="4-agent-company-multiple-digital-employees-collaborate">4. Agent Company: Multiple Digital Employees Collaborate</h3>

<p>This stage is still early.</p>

<p>A real agent company is not created by giving every AI a name or drawing an org chart. The hard part is the collaboration infrastructure:</p>

<ul>
  <li>What is the boundary of each agent’s responsibility?</li>
  <li>Where is the current state stored?</li>
  <li>How does one agent hand work to another?</li>
  <li>When should a human intervene?</li>
  <li>Which actions require approval?</li>
  <li>How can errors be rolled back?</li>
  <li>How is the process audited?</li>
  <li>How are results reviewed?</li>
  <li>How does data flow back into the next round of work?</li>
</ul>

<p>Many products can already demonstrate “one agent does one thing.” But making multiple agents collaborate like a company is not mainly a model problem. It is an organizational system problem.</p>

<h2 id="what-are-digital-employee-companies-actually-selling">What Are Digital Employee Companies Actually Selling?</h2>

<p>On the surface, they are selling AI. Underneath, they are selling three things.</p>

<p>First, they sell cheaper and more elastic labor supply.</p>

<p>This is the easiest story to understand. AI does not sleep, can work 24/7, can scale up instantly, and can be copied. But it is also the most controversial story because it is easily interpreted as simple labor replacement.</p>

<p>Second, they sell measurable work outcomes.</p>

<p>This is more important than replacing people. Sierra’s outcome-based pricing, 11x’s “sell work, not software,” and Decagon’s customer-experience resolution story all point in the same direction: customers no longer want to pay only for a tool. They want to pay for problems solved, leads converted, time saved, and outcomes delivered.</p>

<p>Third, they sell a new collaboration interface for organizations.</p>

<p>When AI can receive tasks, call tools, move workflows forward, and submit results, software is no longer only a system used by humans. It starts to become a collaborator inside the organization.</p>

<p>But this will not happen overnight.</p>

<p>The real enterprise fear is not that AI is not smart enough. It is that AI is not controllable enough: data permissions, hallucinations, compliance, responsibility boundaries, exception handling, audit trails, customer experience, and brand risk can all block deployment.</p>

<h2 id="my-current-view-of-the-market">My Current View of the Market</h2>

<p>In the short term, the most promising digital employee scenarios have three traits:</p>

<ol>
  <li>The task boundary is clear: SDR outreach, customer-service resolution, contract review, reimbursement audit.</li>
  <li>The result is measurable: conversion rate, resolution rate, response time, saved hours.</li>
  <li>The risk is controllable: human review, low-risk workflows, reversible actions.</li>
</ol>

<p>That is why sales, customer service, legal work, IT and HR service desks, finance operations, and code fixes are moving faster.</p>

<p>In the medium term, digital employees will pressure SaaS pricing models. Traditional SaaS charges by seats: who can use the tool. In the agent era, customers will increasingly ask what the agent actually delivers. Outcome-based pricing, task-based pricing, and automation-volume pricing will become more common.</p>

<p>In the long term, the valuable thing is not one agent, but the coordination system around agents. A future company may not be only “people + software,” but “people + a managed, auditable, trainable group of digital employees.”</p>

<p>But we should stay sober.</p>

<p>Most so-called digital employees today are still smarter software. A smaller number are becoming role agents that can deliver partial outcomes. A real agent organization that operates like a company is still very early.</p>

<p>So I would not say digital employees are about to replace people.</p>

<p>I would say this:</p>

<p><strong>The real opportunity of digital employees is not removing people from companies. It is moving the low-value repetitive work that humans should not have to endure back into software, and freeing people to focus on judgment, creation, relationships, responsibility, and organizational design.</strong></p>

<p>The hard part is not creating an AI employee.</p>

<p>The hard part is creating an organization where AI employees can work reliably.</p>

<p>That is the real problem the next generation of agent companies will need to solve.</p>]]></content><author><name></name></author><category term="AI" /><category term="Agent" /><category term="Digital-Workers" /><summary type="html"><![CDATA[Digital employees are moving from marketing language into early production use. But the real challenge is not whether AI can replace a job title. The challenge is whether AI can receive tasks, keep state, deliver outcomes, stay auditable, and collaborate inside a real organization.]]></summary></entry><entry><title type="html">The Most Important Thing for a One-Person Company Is a Growing Agent Team</title><link href="https://coland-g.github.io/ai/agent/workflow/2026/05/06/growing-agent-team.html" rel="alternate" type="text/html" title="The Most Important Thing for a One-Person Company Is a Growing Agent Team" /><published>2026-05-06T00:00:00+08:00</published><updated>2026-05-06T00:00:00+08:00</updated><id>https://coland-g.github.io/ai/agent/workflow/2026/05/06/growing-agent-team</id><content type="html" xml:base="https://coland-g.github.io/ai/agent/workflow/2026/05/06/growing-agent-team.html"><![CDATA[<blockquote>
  <p>When colleagues are no longer only humans, but a group of agents that can be trained, coordinated, and improved, a one-person company needs more than a product prototype. It needs an AI workflow that can keep turning ideas into real outcomes.</p>
</blockquote>

<p><img src="/assets/images/agent-company-workflow-cover.png" alt="cover" /></p>

<p>We often talk about AI agents as if they are going to become a “super assistant”: give it a goal, let it plan, execute, report back, and ideally finish everything in one shot.</p>

<p>But the more I experiment with agents, the less natural that model feels.</p>

<p>A more natural shape may be closer to a company.</p>

<p>Not one all-powerful agent, but a group of agent teammates with different responsibilities: one explores ideas, one turns ideas into PRDs or execution plans, one writes code, one monitors data, one runs growth experiments, and one handles notifications and code review signals.</p>

<p>They do not need to be perfect from day one. They do not need unlimited context or unlimited capability. They need to work inside a shared workflow around the same projects and experiments.</p>

<p>The cover image is a visual metaphor: a human lead working with a group of animal colleagues. The point is not the cuteness of the characters. The point is the working relationship between a human and a set of AI roles, each with its own tools, personality, and job.</p>

<p>The idea of an “agent company” is not just a branding exercise. It comes from a practical one-person company problem: if one person or a very small team wants to cover product, content, growth, engineering, data, and user feedback at the same time, simply opening more chat windows does not scale.</p>

<p>What you need is a way to connect AI roles, shared context, experiments, notifications, and review loops into one operating system.</p>

<p>So this article is not about how to give digital employees nice names. It is about a more concrete question:</p>

<p>If we really want AI to amplify the capability of a one-person company, what should the minimum viable coordination system look like?</p>

<h2 id="from-one-agent-to-a-team-of-agents">From One Agent to a Team of Agents</h2>

<p>The problem with a single agent is that it easily becomes an oversized container.</p>

<p>You want it to understand strategy, write copy, analyze data, write code, do growth, remember all historical context, and plan every step by itself.</p>

<p>The result is usually predictable: the prompt gets longer, the tools multiply, the workflow becomes more fragile, and you are no longer sure what the agent is actually accountable for.</p>

<p>The multi-agent intuition is the opposite:</p>

<p>Do not put every capability into one brain. Split the work into smaller, more specific, easier-to-train roles.</p>

<p>For example:</p>

<ul>
  <li><strong>Spark</strong>: expands ideas, adds angles, and explores different expressions.</li>
  <li><strong>Quest</strong>: turns ideas into PRDs, execution documents, or experiment plans.</li>
  <li><strong>Forge</strong>: handles AI coding and turns clear requirements into code.</li>
  <li><strong>Scout</strong>: monitors data, produces daily/weekly reports, and detects anomalies.</li>
  <li><strong>Notification system</strong>: brings GitHub code reviews, event tracking, collection results, and important reminders to the human.</li>
  <li><strong>Blaze</strong>: proposes growth strategies, designs experiments, observes feedback, and keeps iterating.</li>
</ul>

<p>This may sound like anthropomorphizing AI, but that is not the point.</p>

<p>The point is that once work becomes complex, humans naturally need organization. Agents do too.</p>

<h2 id="agent-employees-are-shaped-through-work">Agent Employees Are Shaped Through Work</h2>

<p>There is one counterintuitive lesson here:</p>

<p>Do not expect to fully define every agent role upfront.</p>

<p>On day one, you will not know exactly how Spark should expand ideas, what level of detail Quest should include in a PRD, when Forge should change code directly versus ask a follow-up question, what Scout should monitor every day, or how Blaze should break growth strategy into experiments.</p>

<p>These details are not solved by one perfect system prompt.</p>

<p>They are closer to real company roles. You start with a rough responsibility, let the role do real work, then keep adjusting its boundaries, tools, output format, and collaboration style.</p>

<p>A simple first version only needs to answer:</p>

<ul>
  <li>What is this agent responsible for?</li>
  <li>What context should it read?</li>
  <li>What output format should it produce?</li>
  <li>When should it notify a human?</li>
  <li>When can it move directly to the next step?</li>
</ul>

<p>Then you let it run.</p>

<p>After a few real tasks, patterns become obvious. Some responsibilities are too broad and need to be split. Some tools create more complexity than value. Some outputs are never read and should be removed. Some notifications are critical and should be pushed immediately.</p>

<p>That is why I increasingly believe this:</p>

<p><strong>Agent employees are not defined into existence. They are trained through workflow.</strong></p>

<h2 id="the-hard-part-is-not-roles-but-collaboration-infrastructure">The Hard Part Is Not Roles, but Collaboration Infrastructure</h2>

<p>Giving agents names and writing a few system prompts is not hard.</p>

<p>The hard part is what happens when there are many agents:</p>

<ul>
  <li>How does one agent’s output become another agent’s input?</li>
  <li>How do multiple agents share context around the same project?</li>
  <li>Which data should be stored long-term, and which context is temporary?</li>
  <li>When should the human intervene, and when should the system continue by itself?</li>
  <li>How should notifications work so they do not become noise?</li>
  <li>How do the hypothesis, action, data, and conclusion of each experiment stay connected?</li>
</ul>

<p>If these questions are not solved, a multi-agent system quickly turns from a “team” into a “group chat.” Everyone is talking, but there is no structure, no state, and no real progress.</p>

<p>So the core of a multi-agent workflow is not only the agents themselves. It is the collaboration infrastructure behind them.</p>

<h2 id="replace-messy-conversations-with-projects-and-experiments">Replace Messy Conversations with Projects and Experiments</h2>

<p>One structure we use is to split work into two layers:</p>

<ol>
  <li><strong>Project</strong>: a long-term direction, representing something we are building or validating.</li>
  <li><strong>Experiment</strong>: a testable hypothesis with concrete actions, observable results, review points, and iteration.</li>
</ol>

<p>This is much more stable than opening a chat window and asking an agent to “think about it.”</p>

<p>A useful experiment record should include:</p>

<ul>
  <li>What is the hypothesis?</li>
  <li>Why is it worth testing?</li>
  <li>What action should be taken?</li>
  <li>Who executes it?</li>
  <li>What inputs are needed?</li>
  <li>What metrics should be observed?</li>
  <li>When is human judgment required?</li>
  <li>How should the result be saved and reviewed?</li>
</ul>

<p>With this structure, agent collaboration no longer depends on temporary context inside one conversation. It depends on a shared working record.</p>

<p>You can think of it as a continuously updated company file: every project, every experiment, every data result, and every retrospective lives there.</p>

<p>Spark uses it to expand ideas. Quest uses it to break work into plans. Forge uses it to write code. Scout uses it to analyze data. Blaze uses it to design the next growth experiment. The notification system uses it to decide which signals need to be brought to the human.</p>

<p>The human does not need to repeat the same context five times. The agents do not need to guess the history behind a task.</p>

<h2 id="the-human-role-becomes-clearer">The Human Role Becomes Clearer</h2>

<p>A multi-agent workflow is not about removing the human.</p>

<p>It actually requires the human to take clearer responsibility for a few things:</p>

<ul>
  <li>Direction: what is worth doing and what is not.</li>
  <li>Judgment: how to choose when the data is incomplete.</li>
  <li>Boundaries: what can be automated and what requires confirmation.</li>
  <li>Organization: when to add a new agent and when to merge responsibilities.</li>
  <li>Taste: whether the final output matches the desired style and standard.</li>
</ul>

<p>Agents execute in parallel, organize information, draft documents, implement code, monitor data, and push notifications.</p>

<p>Humans handle direction, judgment, and governance.</p>

<p>This feels more like a small team than a toolbox.</p>

<h2 id="why-this-is-becoming-interesting-now">Why This Is Becoming Interesting Now</h2>

<p>In the past, building a system like this was expensive. You had to build your own task system, notification system, permission layer, data pipeline, and automation scripts.</p>

<p>Now agents have reached an interesting stage: a single agent may not be reliable enough for full autonomy, but multiple small agents working within clear boundaries and stable context can already produce meaningful leverage.</p>

<p>They do not need to behave like senior employees from the start.</p>

<p>A more realistic comparison is that they are junior teammates. You need to give them clear tasks, the right tools, reusable context, and timely feedback. As the workflow accumulates, they become more like real team members.</p>

<p>This is why I think “agent company” will become a useful mental model.</p>

<p>Not because people suddenly enjoy naming AIs, but because once AI moves from single-point tools to collaborative execution units, we naturally need a new organizational structure.</p>

<h2 id="what-we-are-really-building">What We Are Really Building</h2>

<p>In one sentence:</p>

<p><strong>We are not building a stronger chatbot. We are building a workflow system where agent teammates can continuously collaborate around projects and experiments.</strong></p>

<p>In that system, the most important questions are not whether one agent is smart enough, but:</p>

<ul>
  <li>Does it know what it should do?</li>
  <li>Can it access the right context?</li>
  <li>Can it hand results to the next role?</li>
  <li>Can it notify a human at the right moment?</li>
  <li>Can it save experiments, data, and reviews into reusable memory?</li>
</ul>

<p>Once that infrastructure works, adding a new agent is no longer “connecting another chatbot.” It is closer to hiring a new teammate into the company.</p>

<p>It can have a name, a role, tools, a growth path, and collaboration relationships.</p>

<p>That is the interesting part.</p>

<p>The future AI product may not be just one entry point, one assistant, or one copilot.</p>

<p>It may look like a company.</p>

<p>And the first step is to get the smallest version of that company running.</p>

<h2 id="if-you-are-building-your-own-ai-workflow">If You Are Building Your Own AI Workflow</h2>

<p>What we are doing now is a one-person company experiment: using a group of agents and automation workflows to connect product, engineering, content, growth, data, and user feedback into a system that can keep iterating.</p>

<p>We are a team with deep engineering and startup experience. Many of us have spent years building products and full-stack systems, and we are continuously experimenting with AI in practical settings.</p>

<p>We care less about turning AI into demos, and more about questions like:</p>

<ul>
  <li>How can ideas be turned into real products faster?</li>
  <li>How can multiple agents collaborate more smoothly?</li>
  <li>What tools, methods, and workflows make AI useful in daily work?</li>
</ul>

<p>If you are stuck on anything related to AI workflows, model selection, installation, deployment, AI coding, business automation, or multi-agent collaboration, feel free to reach out.</p>

<p>We want to start from real problems, run experiments, build tools, write practical tutorials, and share the lessons and mistakes along the way.</p>

<p>Instead of only writing about concepts, we want this account to become an entry point: you bring the problem, and we use AI plus engineering methods to break it down, test it, and solve it.</p>]]></content><author><name></name></author><category term="AI" /><category term="Agent" /><category term="Workflow" /><summary type="html"><![CDATA[When colleagues are no longer only humans, but a group of agents that can be trained, coordinated, and improved, a one-person company needs more than a product prototype. It needs an AI workflow that can keep turning ideas into real outcomes.]]></summary></entry></feed>