You have an answer. But who organised the work?

How to turn AI from a conversation partner into a working environment — for contracts, business plans and beyond

Sergey Avdeichik · DOBROVOLA · 12 September 2026

Imagine a business plan for a new bakery sitting on your desk. Twenty neatly presented pages, a revenue forecast, a marketing strategy and a persuasive conclusion: opening a second location makes sense. AI wrote the text. The manager asks one question: “Where did this come from?”

Where did the customer numbers come from? Why that rent figure? Have unsold baked goods been accounted for? Who checked that the business would have enough cash to keep going until sales stabilised?

The same scene plays out in legal work. A contract looks professional, but it is unclear which terms the parties agreed, where the payment deadline came from or which version of the law the author relied on.

The problem is not how polished the text looks. A finished document simply does not mean that the necessary work has been done.

I suggest changing the very subject of our conversation with AI. Not just “prepare the result for me”, but “let us organise a process in which that result can be verified”. That requires sources, a clear purpose, a sequence of tasks, working rules and a human decision-maker.

A method that grew out of student practical training

When I organised practical training for students, I wanted to demonstrate more than a new way of writing code. What mattered was giving them experience of an environment where an AI agent works alongside people: helping to explore an idea, drafting documents, carrying out tasks and presenting results.

Andrej Karpathy’s experience with MenuGen — an application that generates pictures of dishes from a photograph of a restaurant menu — resonates with this approach. In his account, he described how quickly the first interface appeared and how much additional work went into integrations and making the application usable. The gap between an impressive start and a finished product turned out to involve a very real engineering process. [1]

For the training, I proposed a sequence: discuss the idea, create a blueprint, investigate possible solutions, write a technical specification, define milestones and tasks, have the agent do the work, and review the result for acceptance. Students needed to understand not only what had been produced, but also why the work was organised that way.

Then it became clear that very little in this sequence was exclusive to programming. Instead of an application, the output could be a contract, a financial model, market research, a training course or a delivery service procedure.

Professional roles broaden in the process. A lawyer does a little process design, an entrepreneur learns to work with data, a teacher defines quality criteria. This does not turn everyone into every kind of professional at once. But it does allow someone to manage a task from beginning to end, bringing in an agent and the right specialists where needed.

The working relationship is not just “human and AI”, but “human — human — agent”. The client explains the situation, the specialist checks the subject-matter details, and the agent helps carry out the work. Shared documents preserve the agreements between them.

This is my own working approach, not a claim to the one correct methodology. It preserves the familiar strengths of professional practice: documentation, version control, verification of source data and accountability for the work. What changes is how we bring all of this together in an accessible working environment.

Start with a conversation, not the perfect prompt

The first stage is to understand what actually needs to be done. An idea rarely looks like a technical specification at the outset. It contains an aspiration, a vague picture of the outcome, a few constraints and a dozen unasked questions.

I recommend starting with a voice conversation with the model. For me, it is a convenient way to develop a thought: recall an example, question an assumption, change perspective and explain what concerns me. There is no need to turn every remark into a polished instruction in advance.

At this stage, it helps to ask the agent to investigate rather than execute: ask questions, suggest alternatives and spot contradictions. “Do not write the document yet. Help me understand what kind of document we need and what information is missing” is a perfectly workable opening.

The advantage is not some special magic in the voice model. The same open-ended conversation is possible in text. Voice is my way of bringing out, sooner, what might otherwise remain unspoken.

A text model helps turn the transcript into a blueprint — a clear description of the proposed work. Who is the work for? What question should it resolve? What is within scope? What information is needed? How will we know that the result is useful?

The transcript provides broad context, but it does not automatically become a set of requirements. Agreed decisions need to be separated from assumptions, the model’s suggestions and rejected options. A casual “we could also…” must not quietly become a mandatory task. A human reads, corrects and approves the blueprint itself.

The next step is a text-based exploration of the options. In a student project, this covers application architecture, data storage, technologies and deployment. In legal work, it covers the research sequence, sources, checks and approvals. In a business plan, it covers the structure of the calculations, available data, ways of testing demand and scenario development.

I call the output of this stage a “cloud of knowledge”: the person has not made every final choice yet, but already understands the range of possible solutions. They now return to the voice conversation prepared, ready to talk through how the work will happen in practice.

The model can then draft a prompt for preparing the specification. Another text model receives the approved blueprint, research notes, a transcript of the decisions and that prompt. The output is a draft technical specification. For a nontechnical audience, it is simpler to call this a workflow brief: inputs, actions, constraints, deliverables and acceptance criteria.

A separate prompt is useful not as a magic spell, but as a saved instruction for assembling the document. Another participant can understand which materials were used and which rules guided its preparation. The final check that it makes sense remains a human responsibility.

GitHub, Linear and the agent: three clear roles

Tool names can make it sound as though everything that follows is only for programmers. But each tool’s purpose can be explained without a technical dictionary.

GitHub is a place for files and their change history. Think of a repository as a project folder where you can see what changed and who changed it. It is not just for code: GitHub supports files, collaboration and version history. [2]

In my approach, a project has two repositories. The first is where the thinking develops: the blueprint, research, discussions, specifications and decisions. The second is where the output is created: application code, a draft contract, calculations or course materials.

The first repository is a kind of frontier for the project’s documentation. It is a space to think freely, save new ideas and preserve rejected options without immediately turning them into work. The second shows what has actually been done. Agreed requirements do not need to be copied into several places: it is better to link the documents and the deliverables.

A draft must be labelled as a draft, an approved document must have a date and a version, and an outdated document must not pretend to be current. A clear starting file with a map of the materials is more useful than a vast archive with no signposts. Important explanations are easy to keep in plain text; complex spreadsheets and documents can be accompanied by a short description of changes.

Linear is the control desk for the work. It shows what needs to be done, which milestone a task belongs to, what has already been checked and what is blocking progress. Milestones in Linear let you group tasks by project stage and track their completion. [3]

An AI agent carries out the work in a prepared environment. Codex or Claude Code, for example, can fill this role. Codex can work with files, make changes and run available tools. Those capabilities can be used not only for programming, but also for data processing or document preparation. This is a way of using an agent environment, not a promise of a ready-made industry solution. [4]

Connections give the agent access to external tools and context; what they can do depends on the integration and the permissions granted. [5] An agent can therefore help set up a project, organise materials and prepare tasks, but its promise alone is not evidence that access is working. A simple test is needed: did it actually read the right file, create a task in the correct project and return a link to the result?

GitHub should not become a store for all the company’s secrets. Raw client documents, personal information and financial exports can remain in an approved corporate storage system, while the project keeps an inventory and controlled links to them. Where data will be stored must be decided before it is uploaded, not afterwards.

Two repositories are my recommended way to separate these areas, not an end in themselves. For a first small experiment, two folders and a simple task list are acceptable. What matters is keeping the boundary between thinking and execution. Once that distinction is clear, it is easier to move to a full working environment rather than learn several services at once just to tick a box.

Case one: a contract that can be verified

Suppose a small bakery is buying equipment and needs a draft supply contract. This is an educational example of how to organise the work, not a legal opinion on a specific transaction.

The most direct approach is to ask the model to write the contract. But it is more useful to first establish what is being purchased, who the supplier is, where the parties are located, who will install the equipment and how its working condition will be confirmed. What matters most to the buyer: the delivery date, having it running before opening, servicing or the ability to cancel the purchase?

First, a blueprint for the process

The goal might be phrased like this: prepare a draft contract that reflects the agreed terms of the transaction, identifies disputed issues and can be passed to a lawyer for review.

The blueprint records the parties, applicable law, relevant dates, source materials and scope of the research. For an existing dispute, the dates of the events must be established separately and a lawyer must help determine which versions of the rules apply. For a future transaction, known changes that may affect performance need to be considered. The model must not silently be left to choose the country, date and legal framework.

A principle is established here too: first gather facts and supporting grounds, then prepare conclusions. The commercial offer, correspondence between the parties and equipment specification are needed alongside legal sources. Legislation cannot tell us what delivery date the parties actually agreed.

Next, a brief for sources and checks

After exploring the options and discussing the decisions, a workflow brief is created. The agent must find relevant legislation in official sources, save permitted copies in the project folder or approved storage, and create a source register. If case law is material to the question, searching for it is specified separately.

For Polish law, for example, the government’s ELI portal can be a starting point. It distinguishes between published texts, consolidated texts and versions prepared for information purposes. That alone is a reason not to download the first file you find and call it “the law”. [6]

Each document in the register needs a title, an official URL, a version, relevant dates and an explanation of why it has been included. The download date is no substitute for the date a provision took effect. A conclusion depends on the specific article or paragraph, its applicability to the situation and any exceptions. All of this forms part of the specialist’s review.

The approved brief prohibits inventing missing details or presenting proposed terms as agreed ones. An unknown payment deadline must remain a question for the parties. Every material legal conclusion is accompanied by a specific supporting source; where the grounds are insufficient, the uncertainty is flagged.

The collected body of sources allows the work to rely on more than the model’s memory. But missing documents are not the only cause of fabricated answers: models can be confidently wrong and must have the option of acknowledging uncertainty. [7] A folder full of legislation is therefore not a guarantee in itself. Both the text used and whether it actually supports the conclusion need to be checked.

Milestones defined by outcomes, not activity

Three clear milestones are enough for this process: “Facts and legal grounds verified”, “Draft contract and list of disputed terms prepared”, and “Lawyer has reviewed the draft; the parties’ decisions are recorded”.

For now, only the first milestone is broken down in detail. It might contain four tasks: collect the transaction materials; find the legal sources; check versions and applicability; and prepare a list of gaps for the lawyer and client.

Acceptance of the first milestone is not a message saying “legislation reviewed”. It means accessible documents, a register of supporting sources, verified facts and open questions. A critical gap cannot be closed with a general promise to “clarify later”: it requires a decision by the lawyer and client. Only then is a specific assignment to prepare the draft contract created.

During the final review, it helps to work backwards from each important clause: is this a statutory requirement, a term from the correspondence or a proposal still to be discussed? Who confirmed the price? Where is equipment acceptance described? Are there any remaining contradictions between the contract and its appendix?

The result is a draft for informed negotiation and approval, not an automatically signed contract. Sending the document to the counterparty and signing it remain separate actions for an authorised person. Sometimes a useful outcome is a decision not to approve the transaction until the delivery or servicing terms have been clarified.

Case two: a business plan that can say “do not open”

Now the owner of the same bakery is considering a second location. They want a business plan, a financial model and marketing proposals. This is another educational scenario; all the figures below are hypothetical and do not describe an actual bakery or market.

In the conversation with the agent, it is worth changing how the goal is framed. Not “justify opening”, but “find out under what conditions opening makes sense and what level of risk the company can accept”. Otherwise, the desired conclusion can easily become an unwritten requirement for the entire study.

The blueprint starts with the owner’s decision

We need to define the question, the options being compared and the constraints. A new location may be competing for funding with expansion of the first one, delivery services or equipment upgrades. It is important to state in advance the acceptable investment, the cash reserve and the conditions under which the project will be stopped.

Text-based research then begins: what data will be needed, how demand can be tested and which expenses are commonly overlooked in this particular model. After discussing the options, the owner talks through the chosen approach, and those decisions are used to prepare the workflow brief.

The brief may require a twelve-month model, several demand scenarios, a start-up cost plan, cash-flow projections and a separate list of assumptions. The marketing plan becomes part of testing the economics rather than an attractive standalone appendix.

Sources matter more than a confident forecast

The agent collects authorised sales exports from the first location, purchasing and waste figures, offers for premises and equipment, and staffing cost calculations. It can search public sources for available rental offers and information about competitors. Every number needs an origin and a date.

But an advertised rent is not the same as the final terms of a lease. Sales at the first location do not prove demand at the new address. Where data are missing, a useful task output is to identify the gap and propose a test: observe footfall, run a small sales trial or request a commercial offer.

The first milestone could be called “Source data collected and key assumptions identified”. It contains four tasks: check sales and costs; collect offers for the location and opening; describe how demand will be tested; and agree on the starting parameters. Acceptance depends not on the number of files but on a clear distinction between a fact, a preliminary offer, a calculation and a hypothesis.

One number changes the entire conclusion

Consider a hypothetical model. Average revenue per transaction is PLN 25, excluding VAT. The location operates 30 days a month. Variable costs are 45% of revenue; hypothetical fixed cash costs, including wages and rent, are PLN 45,000 a month.

At 100 transactions a day, monthly revenue is:

100 × 25 × 30 = PLN 75,000.

After variable costs, 55% of revenue remains, or PLN 41,250. After fixed costs, the result is minus PLN 3,750.

At 140 transactions a day, revenue rises to PLN 105,000, and the result of the same simplified model becomes plus PLN 12,750. One assumption made the difference: the number of purchases per day.

The threshold for covering these costs is calculated as follows:

45,000 ÷ (25 × 0.55 × 30) ≈ 109.1 transactions a day.

As a practical reference, that is around 110 transactions a day. This is not the point at which all investment has been recovered, nor is it net profit: start-up investment, depreciation, financing, taxes and the specifics of cash flow are not included here. They must be considered separately before deciding to open.

Now the question from the beginning of the article returns: where did the assumption of 140 transactions come from? Is it supported by observations, a sales trial or only the owner’s hopes?

A model can perform the arithmetic flawlessly and still lead to a bad decision if the underlying assumption does not stand up to scrutiny. Calculations should therefore be performed in a spreadsheet or program with explicit formulas, and key results should be recalculated independently.

Marketing must add up too

The suggestion to “attract customers through advertising” does not answer the question of how much extra demand will cost. If a monthly advertising budget of PLN 5,000 is added to fixed costs, all else being equal, the cost-coverage threshold rises to approximately 122 transactions a day.

A marketing task must therefore produce not just an appealing promotion plan, but a testable hypothesis: which channel, what cost, what expected result, how it will be measured and when an unsuccessful experiment will be stopped.

Once the source data have been accepted, the next milestone can be detailed: “Scenarios calculated; sensitivity and cash requirements understood”. The final milestone is the owner’s decision with its conditions recorded. During acceptance review, demand, rent and purchasing costs are varied to see how they affect the calculations and the cash reserve.

The outcome may be “open under these conditions”, “test demand first” or “these premises are unsuitable”. A good business plan does not have to support the owner’s original wish.

Plan the next milestone from reality

One constraint applies to both examples: there is no need to turn the entire project into a hundred detailed tasks in advance.

First, describe the overall route and dependencies. Then break down the next milestone in detail. At the start, I recommend no more than five tasks where possible — few enough for a person to keep their purpose and connections in mind. This is a practical limit on complexity, not a scientifically established number.

Five tasks must not, however, become five bottomless bags. If one cannot be explained clearly and checked, it is better to reduce the milestone’s scope. Emerging defects and questions are recorded honestly, not hidden to keep the number of task cards looking tidy.

Each task should answer simple questions: what must be produced, which materials should be used, what is out of scope and how will the result be checked? In the legal case, “check the sources” means producing a register and review notes; in the financial case, “calculate the scenarios” means delivering reproducible calculations with formulas.

Until people have experience managing agents, I recommend not running several milestones in parallel. First, learn to complete one. The next is detailed after the previous one has been accepted, taking into account the sources found, files prepared, tasks completed and limitations discovered.

For this, the agent receives the current materials from both repositories and the state of the tasks in Linear. It is asked to show what it actually reviewed, rather than assuming that a connected folder has automatically been read.

New information can change the plan. If it turns out that the necessary demand data are missing, the next task becomes testing demand, not polishing the forecast. This is not the method failing; it is the method working as intended.

Two loops need to develop

This kind of work produces two outcomes. The first is the work product itself: a contract, calculation, study or application. The second is an improved environment in which the next similar piece of work will be carried out.

An agent environment has its own instructions. Codex uses AGENTS.md files, while Claude Code uses CLAUDE.md. These set the project context and working rules. They are ordinary text documents, not material accessible only to programmers. [8, 9]

In our bakery, the rules might read: do not present assumptions as facts; do not change agreed source data without a separate record; include formulas with calculations; refer disputed legal questions to a specialist; do not send documents to external recipients without permission.

Roles can also be simple: investigate, execute and check. A first project does not require three agents running simultaneously. One agent can help at different stages, while a person makes decisions and brings in a specialist where subject-matter review is needed.

Repeated procedures can be packaged as skills: for example, how to create a source register or check a financial spreadsheet. In agent tools, a skill brings together instructions and supporting materials for a particular task. [10]

But written rules are not a substitute for technical access controls. Writing “do not send documents” is not the same as restricting the ability to send them. Permissions, approval for consequential actions and spending limits need to be configured separately. Claude Code’s documentation explicitly distinguishes contextual instructions from enforced settings. [9]

After each milestone, I suggest a short review: what worked, which assumption proved wrong, where time was lost and what kept recurring. If productivity drops sooner, there is no need to wait until the milestone ends. If the agent systematically uses an old document version, we need to fix not only the answer but also the way it accesses current materials.

Nor should every failure be blamed on a “bad prompt”. The cause may lie in the task definition, sources, access rights, a tool, a calculation or verification. Take one specific incident, trace it through and only then change the rule. Remove contradictions rather than endlessly adding instructions.

Two loops develop: what we do and how we do it. Improvement in the second is tested on the next comparable task: are there fewer repeated errors, manual revisions and costs?

“Done” is not a status in a task tracker

A completed task card proves nothing on its own. Acceptance is an observation agreed in advance: a source can be opened, a calculation repeated, a disputed term explained or the main scenario reproduced.

For a contract, it is important to show the connection between facts, legal provisions, chosen terms and the lawyer’s decision. For a business plan, it is the origin of the numbers, formulas, sensitivity and the limits of the model. An agent can help check the work, but its second confident message is not independent confirmation of its first.

At the end of each milestone, I suggest asking two questions.

Can I explain the current milestone and its tasks in plain language to someone outside the project?

If the agent becomes unavailable tomorrow, will I be able to understand what was done and why it was done that way?

The second question does not require the ability to replace every specialist and rewrite every program yourself. It checks whether people hold the understanding of the process or whether it has remained inside a conversation that may disappear.

Start with one process, not an “AI transformation”

For a first implementation, I would choose a bounded, recurring piece of work: prepare a contract package, reconcile source data for a report, analyse the causes of delivery delays or gather materials for a lesson. Not the entire legal department, finance function or logistics network at once.

Before starting, it helps to record the current process: who does the work, how much involvement it requires, which errors are costly and who is authorised to accept the result. Then complete one full cycle with an agent and compare not just the speed of the first answer, but the total time, including checks and rework.

In manufacturing, this might be preparing a report on quality deviations; in services, analysing recurring customer enquiries; in logistics, investigating missed deadlines. These are directions for limited pilots, not a claim that one configuration works equally well in every industry.

Staff training makes sense when built around such a process. Employees learn not to collect prompts, but to define tasks, assemble context, check supporting evidence, recognise the limits of automation and improve working rules. The team retains not just experience of talking to a model, but a reproducible procedure.

Not every short task needs a blueprint, two repositories and a task tracker. The lower the cost of error and the need for repetition, the simpler the organisation should be. The method is useful where work lasts longer than one conversation, draws on several sources, passes between people or requires a decision that can be explained.

Sometimes the best result is not to proceed

A legal process may end with a decision not to sign the contract in its proposed form. A financial process may end with a decision not to open a second location at the chosen address. If that decision rests on verified grounds, it is neither an agent failure nor an unsuccessful project.

After all, we did not start out with the goal of producing more text. We wanted to understand the situation better and make a decision whose consequences people would have to live with.

That is why I suggest looking at AI not only as a conversation partner we can ask questions, but also as a participant in organised work. Two things should remain at the end: a verifiable result and an improved way of producing it.

Then “Where did this come from?” stops being an unpleasant surprise. There is a calm answer: here are the sources, here are the assumptions, here are the checks that were performed — and here is the decision a person made.

About the author

Sergey Avdeichik is an AI systems engineer, researcher and digital product developer. He supervises student practical training, develops his own methods for working with AI agents, trains staff and implements AI-assisted processes in companies. This work centres on a concrete task, preparing people, verifiable results and keeping expertise within the team.

Website: dobrovola.dev · LinkedIn · Facebook

Which process in your work is ready for this kind of environment — and at which stage do you find it hardest to verify the result? I would be glad to discuss specific examples.

Sources and further reading

The sequence of work described in this article is the author’s methodology. External sources explain tool capabilities and specific limitations. Both case studies are educational; the calculations use explicitly stated hypothetical data. Reference pages were checked on 12 September 2026.

[1] Andrej Karpathy. Vibe coding MenuGen. The author’s account of building the application, 27 April 2025. Read the article.

[2] GitHub Docs. About repositories. Files, collaboration and change history. Official documentation.

[3] Linear Docs. Project milestones. Project milestones and their associated tasks. Official documentation.

[4] OpenAI. Codex CLI. Working with files, commands and repeatable procedures. Official documentation.

[5] OpenAI. Model Context Protocol. Connecting tools and external context. Official documentation.

[6] ELI, Poland. European Legislation Identifier. Official legislative sources and legal-text version labels. Government portal.

[7] OpenAI. Why language models hallucinate. Causes of confidently incorrect answers and the acknowledgement of uncertainty, 5 September 2025. Research article.

[8] OpenAI. Custom instructions with AGENTS.md. Project context and instructions for Codex. Official documentation.

[9] Anthropic. How Claude remembers your project. CLAUDE.md; the distinction between instructions and technically enforced restrictions. Official documentation.

[10] OpenAI. Skills. Reusable instructions and supporting files for an agent. Official documentation.