DEV Community: Alex Agafonov

YAML manifests for AI developer teams

Alex Agafonov — Thu, 09 Jul 2026 11:43:54 +0000

Most conversations about AI agents start with behavior.

The agent writes code, opens a pull request, updates a ticket, stores memory, calls an MCP server, or moves a task through a workflow. At least, that is usually where the discussion begins.

The behavior matters.

But there is a layer before behavior that is easy to skip: how the team itself is described before anything runs.

That description has to answer practical questions about participants, roles, allowed actions, approval points, context sources, memory scopes, and handoffs between implementation, validation, review, and documentation.

If these things are not described explicitly, an AI-assisted system may still work.

It will simply depend on hidden prompts, local conventions, product-specific settings, and human memory.

NexFlow takes a different approach: describe an AI developer team through a set of YAML manifests.

Not because YAML is special by itself.

But because YAML can live in a repository, be read by humans, go through code review, and be validated against JSON Schemas.

What a manifest set is

A NexFlow manifest set is a group of YAML files that describe a project and its team together.

Most files start with shared fields:

specVersion: "0.1"
kind: AgentSet
metadata:
  project: example-project

specVersion says which version of the specification the file follows. kind says what the manifest describes. metadata connects the file to a project and gives people additional context.

In the current draft model, the core set looks like this:

project.yaml - Project identity, maintainers, policies, and manifest locations.
agents.yaml - Humans, agents, roles, responsibilities, skills, capabilities, permissions, context access, and memory access.
agent-definitions.yaml - Versioned behavioral definitions that assemble model, prompt, retrieval, permission, context, memory, autonomy, and extension references.
workflow.yaml - Work stages, steps, dependencies, approval points, and events.
tasks.yaml - Tasks, owners, participants, dependencies, artifacts, and acceptance criteria.
handoffs.yaml - Transfers of responsibility between participants.
permissions.yaml - Rules that allow, deny, or require approval for capabilities.
capabilities.yaml - Capabilities, risk levels, categories, and audit guidance.
context.yaml - Context sources, source types, access modes, classification, and refresh rules.
memory.yaml - Memory scopes, retention, ownership, visibility, sensitivity, and consumers.
providers.yaml - Provider-neutral model classes and provider selection constraints.
model-profiles.yaml - Provider-neutral model selection profiles and review expectations.
prompt-sets.yaml - Versioned prompt material and safety review status.
retrieval-profiles.yaml - Retrieval expectations for declared context sources.
events.yaml - Event names, expected data, retention, and audit requirements.
extensions.yaml - Integration namespaces, lifecycle state, and required capabilities.

At first glance, that may look like a lot of files.

But the goal is not to make configuration look impressive.

The goal is to stop hiding different questions inside one prompt, one agent profile, or one product settings page.

The smallest useful team

The examples/minimal-team directory shows the smallest useful NexFlow shape: one human maintainer and one agent that helps with documentation.

The project policy is conservative:

defaultAutonomy: ask_before_changes
policies:
  requireReview: true
  secretHandling: Raw secrets are never stored in manifests.
  networkAccess: Disabled unless a task explicitly requests approval.
  destructiveActions: Human approval required.

Even this small example already says a lot.

The documentation agent is not described as a magical autonomous employee. It prepares documentation changes for maintainer review. It can read declared context and draft a change. But that does not mean it has broad authority over the project or access to arbitrary actions.

In agents.yaml, its responsibilities, capabilities, permissions, context, memory, and autonomy level are explicit:

- id: docs-agent
  displayName: Docs Agent
  role: technical_writer
  description: Drafts documentation updates for maintainer review.
  permissions:
    - docs_write_with_review
  capabilities:
    - read_repository
    - modify_documentation
    - read_context
  contextAccess:
    - repository
    - docs
  memoryAccess:
    - ephemeral
    - task
  autonomyLevel: ask_before_changes

For review, this is much more useful than a promise that the agent is smart.

You can see the boundaries in which it is expected to work.

Capabilities and permissions are separate

One of the key NexFlow patterns is the separation between capabilities.yaml and permissions.yaml.

A capability describes which action exists at all.

A permission decides who may use that action, whether it is denied, or whether it requires approval.

For example, modify_documentation can be a medium-risk capability:

- id: modify_documentation
  description: Modify documentation files.
  risk: medium
  category: repository
  requiresApprovalByDefault: true
  auditRecommended: true

But the existence of that capability does not allow an agent to modify files.

Authorization appears in permissions.yaml:

- id: docs_write_with_review
  description: Docs agent may draft documentation changes after review.
  subjects:
    - docs-agent
  capabilities:
    - read_repository
    - read_context
    - modify_documentation
  effect: approval_required
  approvalGate: human_review
  conditions:
    - Documentation changes only.

This distinction matters.

If an action is technically available, that does not mean every participant may perform it. For an AI developer team, this boundary protects against a common mistake: treating tool access as permission.

A software team example

The examples/software-team directory is closer to a normal engineering workflow. It includes an implementation agent, a QA agent, a human reviewer, and a documentation agent.

The project describes approval gates:

approvalGates:
  - id: code_review
    description: Reviewer approval required before merge.
    requiredApprovers:
      - reviewer
  - id: dependency_approval
    description: Maintainer approval required before installing dependencies.
    requiredApprovers:
      - reviewer

The implementation agent is described around limited changes, and its actions still go through permission rules. The QA agent is described around validation evidence. The reviewer remains the human authority for approval and acceptance. The documentation agent updates user-facing materials after review.

That is much clearer than saying: "we have a coding agent."

The manifests separate roles:

implementation prepares changes;
QA collects validation evidence;
the reviewer makes decisions;
the documentation agent updates materials.

And they separately describe actions:

reading the repository;
modifying files;
creating branches;
running commands;
creating pull requests;
approving changes;
updating documentation.

When a team is described this way, review becomes concrete.

You can open the manifests and ask: should execute_command require approval? Should create_pull_request belong to the reviewer? Is memory scoped too broadly? Is context access narrow enough?

Tasks and handoffs

Agents are not enough.

A team also needs a model of work.

In tasks.yaml, you can describe units of work: implementing a feature, testing, review, or documentation updates. Each task can have an owner, participants, dependencies, artifacts, required capabilities, and acceptance criteria.

workflow.yaml connects tasks into stages, for example:

implementation -> validation -> review -> documentation

handoffs.yaml shows how responsibility moves between participants.

That is important because real risk often appears not inside a single action, but at the boundary between actions: who handed over the task, what counts as done, which artifacts must be attached, and who accepts the next step.

Context and memory are not hidden in the prompt

The manifests also make context sources and memory rules visible.

Context answers the question: where may an agent get information from?

That may include repositories, documentation, issues, notes, knowledge bases, web sources, or MCP servers. A source should have a type, access mode, classification, freshness expectations, and limits.

Memory answers a different question: what may the system keep after the task is finished?

Memory may be ephemeral, task-scoped, project-scoped, team-scoped, user-scoped, or organization-scoped. The wider the memory scope, the more careful the write rules should be.

If these boundaries are not described, an agent may look useful, but the team will not understand which information it used or what remained in the system afterward.

This is a specification, not a runtime

It is important not to confuse manifests with execution.

YAML files do not run agents by themselves. They do not isolate credentials. They do not enforce permissions. They do not create provider integrations.

NexFlow currently describes the language, schemas, examples, and rules that future tools could use to say honestly what they support.

But a specification is useful before a runtime exists.

It lets a team see the work model in advance: who participates, which actions exist, what is allowed, where a human is required, which sources may be read, which memory is acceptable, and which events should be auditable.

That does not make an AI developer team magical.

It makes it reviewable.

Capabilities, permissions, and approval gates in AI developer teams

Alex Agafonov — Thu, 02 Jul 2026 11:37:21 +0000

There is a shortcut in AI tooling that looks convenient at first.

We connect a tool, an MCP server, a GitHub integration, a local command runner, or a task tracker. After that, the interface starts to suggest that the agent now "can" work with repositories, tasks, pull requests, files, and commands.

But for a serious team, that is not enough.

Technical ability is not the same as permission. And even an allowed action may still need a human decision.

That is why NexFlow separates these things.

For context, NexFlow is an open specification-first project for describing AI developer teams before running them: agents, capabilities, permissions, context, memory, handoffs, and human approval gates.

A capability answers one question: what can an actor or integration technically do?

A permission answers another question: is a specific subject allowed to use that capability?

An approval gate adds a third layer: does the action require explicit approval before it happens?

This may look like a small distinction. In practice, it decides whether an AI-assisted workflow can be reviewed, or whether it depends on the hope that "the agent will understand."

Skill, capability, permission

It is better to start with the vocabulary, because this is where the confusion usually begins.

A skill describes role suitability. For example: schema_review, backend_review, or documentation_writing. It says that an actor is suitable for a type of work.

A capability describes the action surface. For example: read_repository, write_repository, create_pull_request, execute_command, read_context, modify_documentation, or deploy_application.

A permission describes a policy decision: allowed, denied, or allowed only after approval.

An approval gate describes who or what must approve a gated action.

In one sentence: an agent may have the skill for code review, an integration may expose the capability create_pull_request, but a permission still has to say whether this agent may create a pull request, and an approval gate may require human review before the action.

This matters in NexFlow because agents, humans, automation systems, and integrations are part of the same team description. A connected tool should not automatically authorize every actor.

Capability makes the risk surface visible

A capability does not allow anything by itself.

But it makes risk visible.

A simplified capability example:

specVersion: "0.1"
kind: CapabilitySet
capabilities:
  - id: create_pull_request
    description: Open or update a pull request in a declared repository.
    risk: medium
    category: source_control
    requiresApprovalByDefault: true
    auditRecommended: true

This record does not say that an agent may open a pull request.

It says that the project contains an action with a specific risk profile. A reviewer can see this action surface before any runtime tries to execute it.

For high-risk actions, this is especially important:

specVersion: "0.1"
kind: CapabilitySet
capabilities:
  - id: execute_command
    description: Run approved local commands such as tests or linters.
    risk: high
    category: runtime
    requiresApprovalByDefault: true
    auditRecommended: true

execute_command looks familiar in a developer workflow. But it is one of those capabilities that can easily become too broad. Running tests is one thing. Installing a dependency, changing the environment, or executing a destructive command is another.

A capability vocabulary keeps that risk from being hidden inside prompts or UI assumptions.

Permission makes the decision

A permission connects a subject to a capability.

In the draft NexFlow model, there are three practical effects:

allow
deny
approval_required

For example, a docs agent may read a repository without separate approval:

specVersion: "0.1"
kind: PermissionSet
permissions:
  - id: docs_repository_read
    subjects:
      - docs-agent
    capabilities:
      - read_repository
    effect: allow

But the same docs agent may also be explicitly restricted:

specVersion: "0.1"
kind: PermissionSet
permissions:
  - id: docs_agent_no_deploy
    subjects:
      - docs-agent
    capabilities:
      - deploy_application
    effect: deny

That rule is useful even before there is a runtime.

It makes policy reviewable. A person reading the manifests can see not only the role of the agent, but also the boundaries of its actions.

For actions that are allowed only after review, the effect is approval_required:

specVersion: "0.1"
kind: PermissionSet
permissions:
  - id: implementation_write_with_review
    subjects:
      - implementation-agent
    capabilities:
      - write_repository
      - create_pull_request
    effect: approval_required
    approvalGate: code_review

This is not a UI button.

It is a policy boundary.

An actor may be technically able to prepare a change. But the record says that a declared gate is required before a write action or pull request creation.

Integration capability is not actor permission

The most common mistake is to move a capability from an integration to an actor.

For example, a GitHub integration or MCP server may declare that it requires a capability:

requiredCapabilities:
  - create_pull_request

That only means the integration has an action surface related to pull requests.

It does not mean that every agent that can see this integration may create pull requests.

The actor still has to be authorized through permissions. If there is no permission, a future runtime should reject the action. If the permission has the effect approval_required, the action should wait for a gate. If there is an explicit deny, a gate should not turn a denied action into an allowed action.

This boundary protects a project from a strange failure mode: "we connected the tool, so the agent received more authority than we thought."

Deny should be conservative

The NexFlow security model proposes conservative permission evaluation.

The practical order is:

Confirm that the actor has the requested capability declared.
Find applicable permission rules.
Treat explicit deny as strongest.
Treat approval_required as blocked until approval is satisfied.
Treat allow as valid only inside the declared scope.
Reject the action if no applicable permission exists.

This is not bureaucracy.

It protects the project from broad allow rules.

For example, an implementation agent may be generally allowed to work with a repository. But deployment may be denied separately. If a broad allow wins, the safety rule becomes decoration. If explicit deny wins, project policy stays predictable.

An approval gate should not bypass deny either.

If an actor is denied deploy_application, an approval request should not make deployment acceptable. The permission policy has to change; the team should not rely on an approve button to override a denial.

What an approval gate is

An approval gate describes a decision point.

A simplified example:

approvalGates:
  - id: code_review
    description: Reviewer approval required before repository writes or pull request creation.
    requiredApprovers:
      - reviewer
    appliesTo:
      - write_repository
      - create_pull_request
    events:
      - review.requested
      - review.completed

A good approval gate should be scoped.

Approval for one pull request should not automatically allow deployment. Approval for one command should not become permanent permission to run commands. Approval for a task memory write should not allow an organization memory update.

In future runtime semantics, approval should carry evidence: who requested it, what is changing, which files or artifacts are affected, what the risk summary says, and which tests or validation outputs exist.

NexFlow does not implement enforcement today.

But the specification vocabulary already makes it possible to describe where human authority should be visible.

Why this is useful before runtime

One question is fair: why write all of this if a runtime does not execute the manifests yet?

Because review starts before execution.

A team can read the manifests and see:

which risky capabilities exist at all;
which actors may read the repository;
who may write files;
where approval is required;
which actions are explicitly denied;
where an extension requires capabilities but does not grant authority by itself.

That is already better than discovering permissions through scattered prompts, local settings, and team memory.

NexFlow is still a specification-first project. The repository contains draft documentation, schemas, examples, and RFCs. Runtime enforcement, provider integrations, and a reference CLI are all future work.

But capability, permission, and approval gate are already useful as a language for review.

Because in an AI developer team, what an agent can do is not enough.

What matters is what the project says the agent may do.

And where a human must stop the action before it becomes a side effect.

NexFlow: a common language for AI developer teams

Alex Agafonov — Tue, 23 Jun 2026 10:31:26 +0000

This article did not start as an abstract attempt to invent yet another standard.

It came from practice.

I use AI agents a lot in software development, documentation, project research, knowledge-vault maintenance, task planning, and sometimes even ordinary work scenarios. The more I work with them, the more one repeated problem becomes visible.

We often think we are talking about the same thing.

In practice, we often mean different things.

There are more AI-assisted development tools now. More agents. More copilots. More automation layers. Many products talk about workflows, memory, context, tools, permissions, approvals, MCP, agents, and human-in-the-loop systems.

But a shared language is still missing.

One tool says "agent" and means a chat interface with repository access. Another says "agent" and means an autonomous worker. A third says "workflow," but that may mean a prompt chain, a CI pipeline, a task plan, or just a nice diagram. "Memory" can mean chat history, a vector database, project notes, a user profile, or organizational knowledge. "Permission" can mean a system prompt, an approve button, a GitHub token, a policy file, or an informal team agreement.

As long as one person works with one assistant, this is tolerable.

But when work involves several people, several agents, several repositories, several tools, and real actions inside a project, the problem becomes serious.

At that point, the question is no longer only how smart the model is.

The question is how the work itself is described.

The Problem Is Not Only Agents

In AI developer tooling, we often jump too quickly to the question: "What can this agent do?"

That question matters. But before it, there are more boring and more fundamental questions.

Who participates in the project? What is each actor responsible for? Which context sources may be read? Which ones are off-limits? What memory can survive after the task? Which actions can an agent only suggest, and which actions can it perform? Where is review required? Who approves risky changes? What counts as a handoff? What should appear in the audit trail?

If these things are not described explicitly, the system may still work.

It will simply work through habits, hidden prompts, tool-specific settings, and human memory.

That is fine in the beginning. It does not scale well.

When AI becomes part of engineering work, the missing layer is not another beautiful UI or another list of prompts.

The missing layer is something that can be read, discussed, checked, compared, and moved between tools.

In simpler terms: a specification layer.

Why I Started NexFlow

I started NexFlow as an attempt to create that common language.

NexFlow is an open specification-first project for describing AI developer teams.

The repository is public here:

https://github.com/iwizy/NexFlow

The boundary is important: NexFlow is not an AI coding agent, an LLM wrapper, a chat application, or a production runtime.

At this stage, it is a specification, documentation, JSON Schemas, reference examples, and an RFC process.

I wanted to start with the language, not with the runtime.

If you start with a runtime too early, it is easy to hard-code your current preferences into it: a specific provider, a specific memory model, a specific permission model, a specific workflow. Then the specification becomes just a description of one product.

I wanted the opposite.

First, describe the language.

How can a team declaratively describe a project, agents, tasks, handoffs, permissions, capabilities, context sources, memory scopes, providers, events, and extensions? How can this stay simple enough to read, but structured enough to validate with schemas and maybe execute later?

The current version is still an early draft.

But it is already useful as a way to discuss the work more precisely.

Capability Is Not Permission

One of the central distinctions in NexFlow is capability versus permission.

A capability is what an actor can technically do.

For example: read a repository, modify a file, create a pull request, execute a command, access Linear, call an MCP server, or read documentation.

A permission is a policy decision: whether that action is allowed, denied, or approval-gated.

In practice, this distinction sounds obvious. In real AI tools, it is often blurred.

If an agent can technically call a tool, does that mean it is allowed to call it? If it can read a GitHub issue, can it edit the issue? If it can see documentation, can it save the result as long-term memory? If it has local filesystem access, can it write anywhere?

In a serious system, the answer should not depend on the mood of the current chat.

It should be declared explicitly. A capability should not automatically authorize action.

That is a small distinction, but a more governable system can be built around it.

Context Should Be Explicit Too

An AI agent does not work in empty space.

It reads repositories, tasks, documentation, design files, issue trackers, knowledge bases, decision history, Obsidian vaults, Linear projects, Figma files, MCP servers, web sources, and local files.

But context is not just "give the model more text."

Context has a source, access mode, freshness, classification, owner, limitations, and risk level.

Reading a public README is one thing. Reading an internal roadmap is another. Opening production logs is another. Using personal data is another. Persisting the result into long-term memory is something else again.

If these sources are not described, the AI system begins to operate in a fog.

It feels as if the agent "knows the project."

But where did that knowledge come from? Is it current? Is it allowed? Who authorized the access? What will be retained after the task?

In NexFlow, context sources should be declared explicitly.

Not because that looks elegant.

Because without it, security, quality, and responsibility are hard to discuss honestly.

Memory Should Not Be Magical

Everyone wants AI to "remember the context."

I want that too. But memory without boundaries quickly becomes a junk drawer, a privacy risk, and a source of strange decisions. Especially when an agent carries context from one task into another, from one project into another, or from one user into another.

So memory should not be described as a vague "let the agent remember."

It should be scoped.

Ephemeral memory for the current interaction. Task memory for a specific task. Project memory for a project. Team memory for a team. User memory for an individual. Organization memory for an organization.

Each scope should have retention, ownership, visibility, update rules, sensitivity, and allowed consumers.

That sounds bureaucratic only until an agent saves the wrong thing, uses it in the wrong place, or confidently relies on outdated information.

Memory should be useful.

It should not be uncontrolled.

Handoff Matters More Than It Seems

In a normal team, we intuitively understand how work moves from one person to another.

An analyst prepares requirements. A developer implements. QA checks. A tech lead reviews risk. A manager makes a decision.

In AI-assisted work, handoff becomes even more important.

If an implementation agent finishes a task, what exactly does it hand over to a reviewer? Which artifacts are involved? What are the acceptance criteria? What remains blocked? What was tested? What was not tested? Which decisions were made? Where is human judgment required?

Without a proper handoff, work becomes a stream of messages.

With a proper handoff, the work has state.

And state can be read, reviewed, automated, and retained.

Why Specification-First

It is fair to ask: why not build a CLI or runtime immediately?

Because a runtime without a clear model starts making architectural decisions too early.

It decides how state is stored. How agents are named. How permissions work. How memory is written. How providers are selected. How approvals happen. How events are logged.

Too often, these decisions remain inside one product.

I am interested in a different layer.

A layer that is useful before a runtime exists.

A team should be able to describe a project with manifests: who participates, which agents exist, what they can do, which context sources are available, where approvals are required, which memory is allowed, and which events should be audited.

Even if nothing is executed automatically, that configuration is already useful as reviewable documentation.

The runtime can come later.

Not the other way around.

What Exists Now

NexFlow currently has a draft 0.1 manifest vocabulary.

The core file set includes:

project.yaml, agents.yaml, agent-definitions.yaml, workflow.yaml, tasks.yaml, handoffs.yaml, permissions.yaml, capabilities.yaml, context.yaml, memory.yaml, providers.yaml, model-profiles.yaml, prompt-sets.yaml, retrieval-profiles.yaml, events.yaml, and extensions.yaml.

There is documentation for the core concepts, manifest reference, context model, memory model, autonomy model, capability model, handoff protocol, event model, agent definitions, model profiles, prompt sets, retrieval profiles, extensions, provider abstraction, security, governance, validation, and conformance.

There are practical draft JSON Schemas for the manifests.

There are reference examples for minimal, software, startup, enterprise, and product delivery teams.

There is an RFC process, with accepted project-vision and core-manifest RFCs and several active draft RFCs around conformance, validation, extension namespaces, approval gates, and agent definition versioning.

And there is an important limitation: this is not a runtime yet.

NexFlow does not execute workflows. It does not call providers. It does not run agents. It does not persist production memory. It also does not provide a production CLI yet.

That is intentional.

First the language. Then validation. Then runtime decisions.

What This Means In Practice

The practical question matters too: what does a developer or team get from this description if the runtime does not execute workflows yet?

The answer is simple: a reviewable artifact.

Instead of discussing an AI-assisted workflow at the level of "the agent helps," the team can describe the system explicitly.

For example:

actor:
  role: implementation_agent
  capabilities:
    - read_repository
    - edit_files
    - run_tests
  permissions:
    edit_files: allowed
    push_changes: requires_approval
    delete_data: denied
context:
  sources:
    - repository
    - issue_tracker
    - project_docs
memory:
  scope: task
  retention: temporary
handoff:
  reviewer: human_reviewer
  requires:
    - summary
    - changed_files
    - tests_run
    - open_risks

This is not a final schema and not a promise of runtime behavior. It is an example of the kind of explicitness that matters.

In this form, a team can discuss not an abstract "AI agent," but concrete boundaries: what it can read, what it can change, where approval is required, what memory is retained, what must be handed to the reviewer, and which risks remain open.

Even if the workflow is still executed manually, such a description is useful.

It helps compare tools, prepare reviews, explain security models, design handoffs, and avoid mixing technical capability with organizational permission.

Why This May Matter Later

I do not think every team will start writing AI-team manifests tomorrow.

That is not how these things usually happen.

But I think the need for such a language will grow.

While an AI agent behaves like a personal assistant, chat is enough. But when AI agents become part of development, support, analysis, QA, documentation, release processes, and product delivery, companies will want to know what is actually happening.

Who had access to what.

Why an agent was allowed to perform an action.

Who approved a risky operation.

Which context was used.

Which memory was written.

Why work moved from one actor to another.

What was done automatically, and what was only suggested.

Without a shared language, each tool answers these questions in its own way.

With a shared language, there is a chance for portability, auditability, comparison, and a calmer evolution of AI-assisted engineering.

The Main Point

There is no magic in NexFlow.

Honestly, I like that.

Good foundational systems often look boring at first. They do not promise to replace a team in a week. They do not say an agent will "just do everything." They give a way to describe reality more precisely.

In AI, that matters especially.

The stronger models and tools become, the more important it becomes not only to do something, but to understand who did it, why it was allowed, which context was used, and under whose responsibility it happened.

NexFlow is my attempt to start from that side.

Not from yet another agent.

From a language for describing AI developer teams before they act.

The project is open on GitHub:

https://github.com/iwizy/NexFlow

It is an early draft.

But if we want AI to become a normal part of engineering work, we will need to agree not only on models and tools.

We will need to agree on how to describe the work itself.

Your First AI Pilot Should Be More Boring Than You Want

Alex Agafonov — Sat, 13 Jun 2026 21:00:00 +0000

Companies rarely fail at their first AI pilots because they have no ideas.

Usually, the opposite happens.

There are too many ideas.

The discussion quickly fills with customer support, internal search, a company assistant, an agent for routine work, chat over all documents, automatic request processing, and a few more directions that look excellent on a slide.

At that moment, it is easy to feel the pull of opportunity: we will choose a strong case, build a visible pilot, and show that the company is really moving toward AI.

And that is often where the problem begins.

The first AI pilot is chosen as if its job is to prove that AI is impressive.

But it should prove something else.

It should prove that the company can take a repeatable business process, place AI inside it carefully, check the result, manage the risk, and make a decision after the experiment.

That sounds less exciting.

But this is exactly why a good first AI pilot should often be more boring than you want.

A Demo And A Pilot Are Not The Same Thing

A demo answers one question: "Can we show that this works in principle?"

A pilot answers a different question: "Can we embed this into real work so that something becomes better, safer, or faster?"

That difference is huge.

In a demo, you can use clean examples, prepared documents, a nice interface, and a controlled scenario. The result can look almost magical.

Real work is rougher.

Documents are outdated. Data lives in different places. People phrase requests in messy ways. One team has proper templates, another keeps everything in people's heads. Legal does not want AI to send anything by itself. Security asks which data leaves the company. Business wants a metric. IT wants to understand who will support it later.

And suddenly the main question is no longer "can the model answer?"

The main question is whether there is a real workflow around the model.

The First Pilot Is Already A Small Management System

If a pilot is just a demo, it only needs to show that the model can respond.

If a pilot is a step toward real implementation, it already has to behave like a small managed system.

That does not mean the first pilot should become a heavy governance program from day one. But some management elements should exist from the beginning.

The team needs to understand the context of use. Where exactly is AI used? Inside the team? In customer work? In decision preparation? In a critical process or in a safe draft?

The team needs to understand risk. What happens if AI is wrong? Does a human simply fix a draft? Does a customer receive an incorrect answer? Does bad data enter a system? Does someone make a decision based on a weak output?

The team needs to understand review. How will the result be checked? By a person, a rule, comparison with a reference set, user feedback, or a combination of signals?

And the team needs to understand what happens after launch. Who looks at mistakes? Who changes the prompt, retrieval, data sources, or scenario boundaries? Who can stop the pilot?

Documents like the NIST AI Risk Management Framework, ISO/IEC 42001, and the EU AI Act describe this logic more formally: governance, risk-based thinking, measurement, human oversight, and controls.

For the first pilot, the same idea can be translated into simpler language.

An AI pilot should test more than the model.

It should test whether the company can define the boundaries of an AI scenario, see the risk, measure quality, keep a human in the right part of the process, and make a decision after the experiment.

Why The Impressive Case Is Often A Bad First Case

The most impressive scenario almost always asks to be chosen first.

A company-wide assistant. A customer-facing bot. An agent that processes requests by itself. A large "chat with all company knowledge."

On a slide, these ideas look strong.

But visible scenarios become too broad very quickly.

If a company-wide assistant gives a bad answer, what exactly failed? The model? The documents? Access rights? Retrieval? User phrasing? Or the whole idea of "an assistant for everything"?

Most of the time, it is a bit of everything.

Then the pilot gets stuck. Everyone understands that the direction matters. Everyone sees that something has already been built. But nobody can honestly say whether it is ready, because readiness was never defined properly.

There is another risk: the impressive scenario starts serving the presentation, not the work.

The team builds something that can be shown.

But not necessarily something people can use calmly every day.

For a first pilot, that is a bad trade.

A Good Pilot Starts With A Process

I would not start with the question: "Where can we apply AI?"

That question is too broad. The answer is almost always: "In many places."

A better question is:

Where do we have a repeatable workflow where AI can help a human prepare a reviewable result?

The value of this formulation is not elegance.

It is constraint.

The process should repeat, otherwise the company cannot learn from it properly. AI should help a human, not immediately replace one. And the result should be something that can be checked: a draft reply, a meeting summary, a contradiction found in requirements, a request classification, or prepared data for a decision.

This is where the line appears between "interesting to try" and "ready for a pilot."

Bad Starting Candidates

Some scenarios may be strategically correct and still be bad first pilots.

"Chat with all company documents" sounds useful. But if the documents are outdated, duplicated, contradictory, and ownerless, AI will not solve that problem. It will simply make the chaos more conversational.

"An agent that does everything by itself" also sounds strong. But once AI starts acting, you immediately get permissions, logging, rollback, approvals, security, cost, responsibility, and the question of who is accountable when the action is wrong.

A process without an owner is another bad candidate. If nobody is responsible for the quality of the process today, AI will not magically create that owner. It will only add another layer of uncertainty.

And scenarios where an error cannot be tolerated are especially dangerous starting points. If an AI error immediately creates serious legal, financial, or reputational risk, that scenario should not be the first pilot without very strong controls.

Good Candidates Look Calmer

A good first pilot often does not look revolutionary.

For example, AI helps a support operator classify a request and prepare a draft reply, while the operator checks and sends it.

Or AI summarizes a meeting and suggests tasks, while the project manager decides what actually goes into Linear, Jira, or another system.

Or AI helps an analyst find contradictions in requirements. It does not decide instead of the analyst, rewrite the product, or become a "smart product owner." It highlights places a human should review.

This does not look like "we replaced a department."

Good.

On the first pilot, you usually do not need to replace a department. You need to build a mechanism the company can repeat: a human understands the input, reviews the output, sees the risk, and can give feedback.

If that mechanism appears, the pilot has already done important work.

Pilot Brief Instead Of A Beautiful Presentation

Before building the first AI pilot, I would create not a presentation, but a short pilot brief.

This is a document of a few pages that fixes the pilot boundaries: which process changes, who owns it, which data is used, where AI enters, what it returns, who reviews the result, and how the decision will be made after the experiment.

The most useful part of this document is the stop condition.

The team should agree in advance when the pilot closes, changes boundaries, or is considered not ready.

For example, if quality is below the agreed threshold, users do not accept the workflow, or support cost becomes higher than the expected benefit.

That is an uncomfortable conversation.

But it is better than the endless "let's just refine it a bit more."

Without a stop condition, a pilot easily becomes a permanent experiment. It does not work well enough, but closing it feels painful. Time has already been spent. There is already a demo. Leadership has already seen it.

Then a month passes. Then another.

Bad pilots often do not die loudly.

They slowly become half-working experiments that nobody wants to own.

Seven Questions Before Launch

If you need to understand quickly whether a scenario is ready to be the first AI pilot, I would start not with the model and not with UI.

I would start with seven questions.

First: which exact process are we improving?

"Knowledge management," "sales support," or "employee productivity" is too broad. You need a living process: who does what, how often, where it hurts, what arrives as input, and what should come out.

Second: who owns the process?

If the process belongs to nobody, AI will not make it manageable. A pilot without an owner quickly becomes an experiment that everyone discusses and nobody decides on.

Third: which data is used?

Not "we have documents," but which documents, where they live, who owns them, what is outdated, what is confidential, what can be sent to an external AI service, and what cannot.

Fourth: what does AI do, and what does it definitely not do?

For example: AI may classify a request, suggest a draft reply, and show the sources used. But it does not send the reply to the customer, change the request status, or promise compensation without an operator.

Fifth: where is human review?

If a human only "can review" in theory, but has no time, criteria, or interface, that is not review. That is self-reassurance.

Sixth: how is quality measured?

The criterion is needed before launch, not after. Otherwise the team argues about impressions: "I like it," "I do not like it," "it seems better," "let's keep watching."

Seventh: what decision will we make after the pilot?

The pilot should not end with "let's refine it a little more." The team should know in advance what would justify scaling, another iteration, a narrower scope, or closure.

A pilot is not meant to be piloted forever.

It is meant to help the company make a decision.

A Simple Scoring Model

If a company has ten AI ideas, I would not rank them by how impressive they look.

I would rank them by where the company can learn fastest how to work with AI as part of a process.

This does not need false precision. The purpose of scoring is to force the team to discuss trade-offs.

I would look at:

repeatability: does the process happen daily or weekly, or twice a year?
pain: is there a real problem, or only curiosity?
reviewability: can a human or rule check the result?
data readiness: do the necessary sources exist and have owners?
risk boundary: can AI suggest, prepare, classify, or highlight while a human decides?
ownership: is someone responsible for process quality?
repeatable mechanism: will this pilot teach the company how to describe data, review, metrics, and stop conditions for future AI scenarios?

If an idea scores high on impressiveness but low on reviewability, ownership, and data readiness, I would not put it first.

It may be strategically important.

Just not now.

The first pilot should teach the company to manage AI, not only admire it.

One uncomfortable thing is worth accepting in advance: good scoring may push down the team's favorite ideas.

That is not a failure of the method.

"Assistant over all documents" almost always sounds stronger than "support request classification with human review." But the first scenario may require a mature knowledge base, access rights, retrieval evaluation, document owners, and a clear update process.

The second scenario may give the company fast and reviewable experience: how AI helps a human, where it fails, which data is needed, and how the feedback loop works.

For the first pilot, I would choose not the largest dream, but the smallest manageable loop that teaches the next step.

Roles Matter More Than They Seem

Another mistake is to give the pilot to only one side.

If it belongs only to business, it may ignore data, security, integrations, cost, and support.

If it belongs only to IT, it may become a technical experiment without a real user.

If it belongs only to AI enthusiasts, it may look beautiful but fail to become part of the workflow.

A normal pilot almost always rests on a connection between a business owner, a technical owner, and an AI scenario owner.

In a small company, these may be one or two people. In a larger company, they are usually different roles. But the functions still need to exist.

The business side understands the process and value. The technical side understands data, constraints, and support. The AI scenario owner connects these worlds: where AI enters, what it receives, what it returns, who reviews the result, and how feedback is collected.

Without these functions, the pilot easily drifts into one of the extremes: a beautiful business slide with no operations behind it, a technical demo with no value, or an enthusiast experiment with no governance and no rules.

A Good Result Is Not Always Scaling

A good result from the first AI pilot is not necessarily "we scale this to the whole company."

Sometimes a good result is an honestly closed pilot.

The team may learn that the data is too messy, the process is not described, users are not ready, the expected effect is smaller than the support cost, or the risk is higher than expected.

That is not a failure if the conclusion is reached quickly and honestly.

The failure is when a pilot continues to live only because closing it would be uncomfortable.

After a normal pilot, the next step should be clear: expand the scenario, change the architecture, first fix the data and process, keep AI only as an internal assistant, or close the direction and choose another candidate.

In all of these cases, the company becomes smarter.

That is one of the goals of the first pilot.

The Main Point

The first serious AI pilot should not prove that AI is magical.

It should prove that the company can choose, constrain, check, and implement AI scenarios.

Do not start with the most impressive case only because it looks good in a presentation. For the first pilot, choose one repeatable process where AI helps a human prepare a reviewable result, and where the team understands the data, owner, risk, metric, and stop condition.

That sounds calmer than AI transformation.

But this is usually how real implementation begins.

Business does not need a beautiful AI project for its own sake.

It needs a new capability: to process information better, lose less context, make working decisions faster, and manage risk more carefully.

The first pilot should be the first step toward that capability.

Not another way to say: "We also use AI."

AI Adoption Is Not Just a Content Factory

Alex Agafonov — Fri, 05 Jun 2026 21:00:00 +0000

There is a very understandable trap in AI adoption: the first visible result is usually content.

Not because content is the most important thing.

It is simply the easiest thing to show.

There was a blank page, and now there is an article outline. There was one idea, and now there are variants for an email, a post, a landing page, or a presentation. There was the fear of starting, and now there is a draft to work with.

That is convenient. It is fast. It really can save time.

And that is exactly why it is easy to confuse it with AI implementation.

A company starts producing more text. Inside the team, there is a feeling of movement. Marketing closes the publishing calendar faster. Sales gets draft emails. HR prepares job descriptions faster. Leadership sees activity and concludes that AI is already working.

Sometimes this is genuinely useful progress.

But if the story ends with text generation, the company did not get AI adoption as a real business capability.

It got AI-assisted content production.

Useful. But not the whole strategy.

№ Why Content Usually Starts First

Content is almost a perfect first testing ground for AI.

You do not need to integrate with a CRM, ERP, ticketing system, or internal document repository right away. You do not need to give the model permission to change data inside systems. You do not need to design a complex security environment at the start.

You can open a chat, describe the task, and get a visible result.

For a first experience, this is convenient.

The risk is easier to understand. The benefit appears quickly. The person feels the tool helping. A manager sees examples. The team gets the feeling that "we have started."

I would not dismiss that stage.

AI really does help with the blank page. It helps create a draft faster. It can suggest formulations. It can reveal weak spots in a text. It can adapt material for another channel.

But then a more important question appears.

What exactly became better in the business?

If the only answer is "we write faster," that is not a very strong answer yet.

№ Text Speed Is Not A New Business Capability

Speed is pleasant to measure.

Previously, a text took three days. Now it takes an hour. Previously, there were two headline options. Now there are twenty. Previously, an employee struggled to start a presentation. Now AI gives a structure immediately.

All of that can be real value.

But the speed of text production alone does not mean the business became smarter, more precise, or more resilient.

You can write emails faster that nobody wants to read.

You can publish more posts that do not change how people see the product.

You can create more landing pages that do not help a customer make a decision.

You can produce presentations faster without adding a new thought.

AI removes friction between an idea and a text very well. But if the idea is weak, positioning is unclear, customer pains are not understood, and the product is poorly explained, AI does not accelerate thinking.

It accelerates packaging.

This is where the difference between output and capability begins.

Output is how many materials were produced.

Capability is what the company can now do better.

If AI helped produce more texts, that is output.

If AI helped the company understand customers better, process requests faster, answer more precisely, reuse knowledge, find contradictions, prepare decisions, and preserve context, that is capability.

A content factory almost always starts with output.

Mature AI adoption should move toward capability.

The Problem Is Not Content

I am not against AI content.

The opposite, actually. A good AI-assisted content workflow can be a strong first step. The problem is not that AI helps write. The problem is that text often becomes a substitute for work that should have happened before the text.

A good article needs a thought behind it.

A good email needs an understanding of the recipient.

A good landing page needs an understanding of the product, customer pain, objections, and the next action.

A good post needs a position, not only a topic.

AI can help formulate all of that. But if the company only asks it to "make a text," it will usually make a text.

Maybe a smooth one. Maybe a pleasant one. Maybe even a convincing one at first glance.

But smooth text does not prove that there is strategy behind it.

When text becomes cheap, value moves toward the quality of thinking behind the text.

That, for me, is the main risk of the content factory: it creates a feeling of activity, but not always a new company capability.

What A Weak AI Content Process Looks Like

A weak scenario is usually very simple.

The team asks: "Write a post about our new feature." AI writes it. Then the team asks to make it friendlier. Then shorter. Then with a call to action. Then the text is published.

On the surface, everything looks fine.

But important questions may never have been asked.

Why does this feature matter? For whom? What did the user do before? What changes now? What are the limitations? What must not be promised? Which facts can be referenced? What should the reader understand? How will the team know whether the material worked?

If those questions are absent, AI becomes a fast copywriter without context.

It may write better than average. But it does not know what was not given to it and what was not organized in the process.

That is why the problem is not only the prompt.

The problem is missing task context.

A normal AI content task needs a goal, audience, constraints, sources, facts, position, format, readiness criteria, and someone responsible for the final version.

That is no longer just generation.

That is workflow.

What A More Mature Workflow Looks Like

A good AI content workflow starts before the text.

First comes the meaning frame: what we are explaining, to whom, why now, and what thought we want to leave with the reader.

Then come the sources: product notes, interviews, research, real customer questions, internal documents.

Then comes the structure.

Only after that does AI help with a draft, variants, shortening, adaptation, and finding weak spots.

The final text should not simply be "the model's answer."

It should pass human review: meaning, facts, tone, promises, legal constraints, product accuracy, and alignment with the company's position.

In this scenario, AI does not replace thinking.

It accelerates the materialization of thinking.

That is a big difference.

And at this point content starts working not only outward, but inward.

Articles can reveal recurring customer questions. Sales emails can reveal objections. Support replies can reveal product gaps. Interviews can become product discovery material. Webinars can become knowledge-base topics.

Content stops being only a stream of publications.

It becomes part of the knowledge system.

That is much more interesting.

Treat Content As A Small Production Pipeline

For a developer audience, I would put it this way: a weak AI content process looks like an ad hoc prompt. A stronger one looks like a small production pipeline.

Not because every article needs Kubernetes around it.

Because the task gets structure.

For example:

goal of the material;
audience;
source of facts;
constraints;
tone of voice;
publication channel;
readiness criteria;
review owner;
list of claims that must not be made;
connection to a product, process, or knowledge base.

Then AI receives not a vague request to "write it nicely," but a task with context.

The difference is visible immediately.

In the weak version, the model tries to guess the company's position.

In the strong version, it helps express a position that has already been clarified.

In the weak version, the text exists separately from product, support, sales, and real customer questions.

In the strong version, the material connects those sources into one useful artifact.

In the weak version, review becomes "I like it" or "I do not like it."

In the strong version, review checks facts, promises, tone, audience fit, and the next step for the reader.

This is much closer to engineering thinking.

Even if the final output is still an article, the process has inputs, outputs, acceptance criteria, and human review.

Content stops being a magical text "made by AI" and becomes part of a managed system.

A Minimal Checklist For A Mature AI Content Scenario

Before calling an AI content workflow useful, I would ask a few questions.

First: where does the meaning come from?

If the only source is "write about our new feature," the text may be smooth but empty. If the sources are customer questions, product notes, support tickets, sales objections, research notes, and internal decisions, the text begins to carry real work.

Second: where are facts checked?

AI can confidently produce a beautiful paragraph out of approximate statements. So the material needs a person or role responsible for factual claims, product promises, legal-sensitive wording, and public positioning.

Third: what returns back into the system?

A good content process does not end with publication. It can update an FAQ, reveal documentation gaps, collect objections, create onboarding material, and help sales and product explain the same idea more clearly.

Fourth: which capability are we developing?

"We write faster" is fine at the beginning. But the next level should be stronger: we formulate our position better, turn internal knowledge into clear materials faster, preserve repeatable explanations, and use publications as part of the knowledge system.

That is when AI content stops being just output.

It becomes a training ground for more mature AI adoption.

There is one more useful sign of maturity: the team starts reusing not only the final texts, but the structure of the work itself.

For example, there is not just one successful post, but a repeatable brief for product explanation. Not just one email, but a template for analyzing a customer objection. Not just one landing page, but a process where facts, constraints, claims, and proof points are checked before generation.

At that point, AI helps with more than "writing more."

It helps the company standardize thinking around repeatable communication tasks.

For a technical audience, this matters especially. They quickly feel the difference between text generated for the sake of activity and text backed by a real work system, constraints, trade-offs, and experience.

What Usually Sits Next To Content

While a company is busy generating texts, stronger AI scenarios often sit nearby.

Support, for example.

AI can do more than write replies. It can classify requests, find similar cases, retrieve relevant knowledge-base articles, warn about risk, and suggest escalation.

Or internal knowledge.

AI can help people find decisions in documentation, prepare project summaries, connect decisions with reasons, and turn chaotic notes into usable context.

Or systems analysis and product work.

AI can help find contradictions in requirements, compare scenarios, check whether a description is complete, and surface edge cases.

This is less visible than a new LinkedIn post.

But this is often where real time savings, fewer errors, and better control begin to appear.

How To Know The Company Is Stuck
Getting stuck in the content factory does not look like failure.

It may look successful. There is more content. The team is happy. Leadership sees activity. Internal presentations show nice examples.

But there are warning signs.

AI barely touches support, sales, product, operations, analytics, or knowledge management.

Success is measured by the number of texts, not by which processes became faster or more accurate.

After the sentence "we accelerated content creation," nobody can explain the next level.

That is not a disaster.

It is a normal early stage.

The important thing is not to live there forever.

What To Do Next

A good next step is not to switch off content scenarios.

Keep them. They provide experience, speed, habit, and a sense of limitations.

But then choose one or two processes where AI improves not the quantity of texts, but the quality of work.

I would look for processes that happen regularly, have a clear pain, work with data or knowledge, produce a reviewable result, and have an owner.

This could be support triage, incoming request processing, internal knowledge search, document review, requirements work, decision preparation, or employee onboarding.

You do not need to start with the hardest thing.

It is better to start where AI can become part of normal work, not a separate hobby for enthusiasts.

The Main Point

Content is a good entry point into AI.

It is fast, understandable, visible, and relatively safe.

But content should not become the ceiling.

If AI adoption ends with text generation, the company gets a communication accelerator, but not necessarily a new business capability.

Real value begins when AI enters processes: helps people work with knowledge, supports decision preparation, speeds up task processing, reduces errors, makes repeatable workflows more manageable, and helps the company not just produce more, but work better.

So after the question "how do we create content faster?" the next question should be:

Which process becomes better if AI helps not only with writing, but also with thinking, searching, checking, connecting, and preparing a decision?

That is where AI stops being a content factory and starts becoming part of the company's operating system.

The Hidden Middle Between ChatGPT Access and Real AI Implementation

Alex Agafonov — Wed, 03 Jun 2026 09:57:10 +0000

AI is everywhere right now. Prompts, content plans, landing pages, chatbots, agents, and promises that a company can "implement AI" almost without effort.

Some of that is useful. Good prompts are useful. Quick personal workflows are useful too. But there is an uncomfortable point: a business can very easily confuse access to an AI tool with real AI implementation.

A company buys ChatGPT, Claude, or another AI tool for employees. A few people start using it actively. Someone writes emails, someone summarizes documents, someone drafts presentations, someone tries to analyze spreadsheets. Inside the company, it feels like something is moving.

And at that moment it is easy to say: "We are implementing AI."

Formally, yes, the first step has been made.

But if we are being honest, access to AI is not implementation yet. It is access.

Why This Conversation Matters Now

It is no longer very useful to argue about whether business needs AI at all. The practical question has shifted.

It sounds more like this: what exactly can a business do with AI besides individual employees opening a chat window and typing requests into it?

This is an important change. While AI remains a personal assistant, the company gets many small accelerations. But business impact does not appear automatically. It appears where those accelerations turn into repeatable work scenarios.

The same pattern keeps showing up in recent enterprise AI reports from OpenAI, Microsoft, McKinsey, and Wharton: access to AI is growing quickly, people use the tools more often, but the constraint is increasingly not the model itself. It is how work is organized around it.

I think that is a very precise frame.

The problem is not that companies "do not believe in AI enough." Often they already do. They are already buying subscriptions, gathering internal groups, running experiments, discussing agents, and building first demos.

The problem is different: between access and implementation there is a layer of organizational readiness.

It is hard to sell as magic. There is no beautiful promise like "press a button and receive AI transformation." There are processes, data, responsibility, security, review, quality, ownership, and metrics.

But this is exactly the layer that decides whether AI becomes part of work or remains a set of personal habits.

Where The Illusion Of Implementation Appears

Imagine a simple company. Leadership buys twenty subscriptions to an AI tool. Then a natural spread begins.

One employee uses it every day and really saves time. Another opens it twice, gets a strange answer, and never returns. A third pastes fragments of customer correspondence into the chat and does not think about privacy. A fourth asks the model to prepare a summary but does not check the facts. A fifth creates strong drafts, but the whole process stays inside their head.

From the outside, this looks like AI adoption.

From the inside, it is more often a set of personal habits.

Some habits are good. Some are weak. Some are potentially dangerous. But this is not a system yet.

A system appears later. It appears when the company understands which processes it wants to improve, which data may be used, who checks the output, where responsibility sits, what counts as a good result, which scenarios repeat, and where AI must not act without human review.

Until that exists, AI lives inside the company as a personal tool used by separate people.

That is a normal early stage. The danger begins when this stage is called full implementation and the company stops moving further.

Access Does Not Create A Workflow

There is a simple test.

If the active employee goes on vacation tomorrow, does the AI scenario remain inside the company?

If the answer is "no," this is probably not a workflow. It is a personal way of working.

A workflow should be describable. It does not have to be a huge document, but it should be clear enough: what comes in, what the person does, where AI helps, what comes out, who checks the result, and how to understand that the result is acceptable.

For example, "AI helps us write emails faster" is not a workflow yet.

But "AI prepares a draft reply to a standard support request based on the customer card and a knowledge-base article, then the operator checks the text and selects the result category" is much closer.

There is a process, an input, a knowledge source, a human role, a responsibility boundary, and a reviewable result.

That is less impressive than "we implemented AI across the company."

But it is much closer to reality.

Where The Substitutions Usually Happen

The first substitution sounds simple: "We bought subscriptions, so AI is implemented."

No. It means employees now have a tool.

That is like buying Excel for every employee and announcing that financial analytics has now been implemented in the company. Excel can be part of analytics, but analytics itself appears only when there is data, models, rules, responsibility, processes, and people who understand what they are doing.

The second substitution is: "We need a chatbot."

Sometimes you really do. But often a chatbot becomes not the solution, but the most familiar image of AI implementation. It is easy to imagine: ask a question, get an answer, show it nicely in a meeting.

But if the knowledge base is chaotic, the bot does not create order. It simply answers on top of chaos.

The third substitution is: "We need agents."

Agents are even more sensitive. An agent does not only answer. It can search for information, call APIs, create tasks, update records, prepare documents, and trigger chains of actions.

That is already action inside a system.

And action requires permissions, boundaries, logging, review, stop conditions, responsibility, and an understanding of consequences.

If the company cannot describe the workflow properly, an agent will not fix that problem. It will simply get the ability to execute a poorly described process faster.

And that is not always good.

Why A Chatbot Does Not Fix Chaos

Another common scenario is that a company decides it needs a chatbot over all documents.

The idea is understandable. There are many documents, people cannot find what they need, and knowledge is spread across Confluence, Google Docs, presentations, chats, and employees' heads. So the company wants AI to provide an answer.

But AI does not turn a chaotic knowledge base into a good knowledge base.

If documents are outdated, duplicated, contradictory, and ownerless, a chatbot will simply make that chaos more conversational. Sometimes it will answer well. Sometimes it will be confidently wrong. Sometimes it will retrieve an old version of a process. Sometimes it will beautifully rephrase something that has not been true for a long time.

And the problem will not only be the model.

The problem will be that the knowledge layer is not ready.

A normal AI scenario needs sources, freshness, access rights, responsibility for data, update rules, and an understanding of where knowledge ends and assumption begins.

Without that, "chat with documents" often becomes a polished wrapper over old disorder.

Why Prompts Do Not Save You By Themselves

A good prompt really matters. I generally think a prompt often works like a small task contract: what needs to be done, for whom, with which constraints, in which format, and according to which criteria.

But a prompt does not replace a process.

You can write an excellent prompt for a commercial proposal. But if it is unclear where current prices come from, who checks legal wording, which customer data may be used, where the final version is stored, and who is responsible for sending it, this is not AI implementation. It is a good text template wrapped around an undefined process.

You can create a strong prompt for call analysis. But if recordings are stored all over the place, customer consent is not properly handled, evaluation criteria are not agreed upon, and managers do not understand what to do with the result, the prompt is not the problem.

A prompt is an interface to the task.

Implementation is when the task, data, constraints, review, and responsibility are connected into a normal working system.

What Sits In The Hidden Middle

Between "we bought ChatGPT" and "AI became part of the business" there is a large layer of boring but important work.

First, you need to choose a repeatable process. Not "let's apply AI somewhere," but "this process happens constantly, takes a lot of time, quality varies, and the result can be checked."

Then you need to understand the data. Which data may be given to the model? Which data must not be given? What needs to be anonymized? What must stay inside a protected environment? Where is the risk of leakage or misuse?

After that, you need to define the human role. At early stages it is almost always more reasonable to start with the model "AI prepared, a human reviewed and made the decision." This is not weakness. It is a controllable way to implement AI.

Then you need quality criteria. Not "the model answers well," but what exactly counts as a good result: faster, more accurate, fewer errors, less manual work, better completeness, less context loss.

And you need an owner. Not an abstract "AI initiative," but a person or role responsible for the process and able to make a decision: continue, change, scale, or stop.

That is the hidden middle.

It does not look as impressive as an agent demo. But it is what decides whether AI becomes part of the business or remains a set of personal shortcuts.

How To Turn This Into A Working Artifact

If we make this very practical, the first result of AI adoption should not be "we bought a tool." It should be a small described workflow.

It does not have to be heavy documentation. But it should at least be a short adoption brief.

It should capture:

which process we are improving;
who owns the process;
which data is used;
which data must not be sent to an AI tool;
where AI enters the process;
what AI returns to the human;
who checks the result;
which errors are critical;
what is logged;
which metric shows that things improved;
under which condition the experiment is stopped or its boundaries change.

This can sound too simple, but this is usually where you see whether there is implementation or only enthusiasm.

If a team cannot describe the input, output, review, and responsibility, it is too early to build a complex agent. First, it needs to understand the work.

If it can, even a simple AI scenario becomes much more serious. For example, not "AI helps support," but "AI classifies incoming requests into five categories, suggests a draft response based on the current knowledge-base article, the operator checks the text, selects the final category, and marks whether the suggestion helped."

That scenario can already be tested.

It has input, output, a human in the loop, knowledge sources, quality, feedback, and a responsibility boundary.

These boring descriptions later become the foundation for stronger AI systems.

There is one more useful sanity check: can this scenario be explained to a new person without a personal handoff of "how we usually do it"?

If it cannot, then AI is not embedded into a workflow. It is embedded into an informal team habit.

For personal productivity, that may be fine. For a business, it is a weak foundation. An employee goes on vacation, a manager changes, the knowledge base changes, and the scenario falls apart.

A good workflow should survive a change of participant. Not perfectly, not without training, but at least at the level of a clear instruction: which data to take, which steps to perform, what to send to review, where to stop, and whom to ask when there is doubt.

This is what separates implementation from a set of successful personal tricks.

So I would not be embarrassed to start with process documentation. For AI adoption, this is not bureaucracy. It is a way to make experience transferable, reviewable, safer to manage, and usable by the next team that comes after the first experiment, with fewer guesses and verbal explanations.

That kind of artifact reduces risk.

Tool, Workflow, System

I find it useful to separate three levels.

The first level is a tool. A person opens AI and accelerates their own task: writes an email, makes a summary, prepares a draft, studies a topic. This is useful, but it mostly remains personal productivity.

The second level is a workflow. AI becomes part of a repeatable process. For example, every incoming request goes through classification, a human checks the result, and the system sends the task to the right queue.

The third level is a system. AI is connected to data, permissions, integrations, logging, review, governance, and a clear owner. Here AI no longer just helps one person. It becomes part of the operational architecture.

Many companies talk about the third level while in practice they are still at the first.

And that is fine if the company honestly sees its current stage.

It becomes bad when a company jumps across several levels and then wonders why "AI did not create business impact."

Where Real Value Begins

Real value does not begin at the moment a subscription is purchased.

It begins when the company starts asking more mature questions.

Not "which AI tool should we buy?" but "which process do we want to improve?"

Not "which bot do we need?" but "which knowledge, data, and decisions need to be available inside this process?"

Not "can AI do this?" but "can we safely embed AI into a workflow so that the result can be reviewed?"

Not "how do we replace a person?" but "where does a person need more speed, context, options, checking, and support?"

Not "let's automate everything," but "where can automation help without destroying control?"

These questions are less impressive, but they are much more useful.

They immediately show that AI adoption is not only about choosing a model. It is about designing work around the model: which data is available, which roles remain with people, which actions require approval, what is logged, how feedback is collected, who is responsible for quality, and what happens when something goes wrong.

In practice, this is exactly where the difference appears between "a person sometimes uses AI" and "AI became part of the operational architecture."

In the first case, knowledge remains in the head of a strong user. In the second case, the company can hand the workflow to another person, check it, improve it, train the team, and scale without depending completely on one enthusiast.

For a business, this is not just operational neatness.

It is a way not to lose the effect after the first successful demo.

What Comes Next In This Cycle

I want to look at AI from exactly this side.

Not only how to write good prompts.

Not only how to produce more content.

Not only how to show an agent that "did everything by itself."

But how a business can approach AI without the illusion that a tool will create a process by itself. How to choose the first use cases. How not to turn AI into a generator of extra text. How to distinguish a chatbot from a knowledge system. Why RAG is not just "chat with documents." Where agents are useful, and where they become dangerous. Why governance, review, and ownership matter.

In short, I am not interested in AI as a magic trick.

I am interested in AI as a working capability of a company.

And the first step toward that capability is to honestly recognize which level we are currently at: tool, workflow, or system.

Key Idea

If a company bought employees access to AI tools, that is a good step.

But it is not the end of the path. It is the beginning.

Real value does not come from the mere fact of access. It comes when the business learns to embed AI into real processes: with clear data, boundaries, review, responsibility, metrics, and an owner.

That is where AI stops being a trendy topic or a personal accelerator for separate employees.

That is where it starts becoming part of the business.