From team learning to a working project

A training example built on fictional data. It follows 4 stages from team training to an implementation project: an employee compares delivery documents and prepares a summary, and the team decides what to check before development and integration.

Let’s talk
From team learning to a working projectPeople. Ideas. Real work.

From learning to launch

We guide your team from learning to a working solution.

An employee compares two delivery descriptions by hand. During training, the group checks whether AI can find differences and quote both sources. They record how to review the answer and handle missing information. A recurring task with a checkable result becomes a candidate for development.

Training

Learn through hands-on practice

Finding a case

Select an opportunity worth testing

Shaping a project

Define data, systems and acceptance

Integrating

Launch and support everyday use

Test the idea on real work

Your team works with its own data, tasks and review criteria.

Participants test several documents, including one with a missing field. They check each quoted difference against the source and record corrections. The project brief sets out the process owner, permitted data, acceptance checks and a manual fallback, giving developers a defined task.

Your taskWork togetherReview and improve

Make it part of daily work

We help you use the solution in real processes and support your team after launch.

After the prototype passes those checks, the team tests it in the place where the task actually happens. The employee still reviews the note before it reaches a manager. The system needs a way to show a missing source, a failed integration and who is responsible for the next step.

Let’s talk

How we work with your team

Majento is based in Tashkent and works with companies in Central Asia, Russia, Belarus and other markets in English and Russian. Process reviews, training and solution testing can take place remotely. We agree on in-person sessions with your team.

Before starting, we confirm the participants, meeting schedule and working materials. For development, we involve your IT team to agree on integrations, data access and acceptance checks.

Meet the team and find our contacts on the company page.

Updated

1. Training starts with a real task

The team brings a task it already performs. In this example, an employee compares two delivery descriptions and prepares a short note for a manager. The baseline is the current document, the time spent and the checks a person makes before sending the note.

Participants practise writing a request with the goal, source documents, rules and output format. They compare the answer with the documents. Missing information stays marked as missing. The model does not get permission to fill a contractual gap.

2. The exercise reveals an opportunity

The case is worth a project only when the work repeats, the input is available and a responsible person can check the result. The team records what helped, where the answer failed and which parts are better handled by a rule or a person.

The register helps the team decide what comes next. Some tasks stop at a checked prompt or a new instruction, and no software is needed.

3. The project card makes the idea testable

For the example, the card would contain:

Project-card field Fictional example
Process owner The person responsible for the note
Inputs Two delivery documents and approved comparison rules
Output A draft with quoted differences and links to both sources
Systems The agreed document store and the place where the note is kept
Acceptance Every quoted difference matches the source, missing terms are visible and a person approves the note
Fallback The employee compares documents manually when the source is incomplete or the system is unavailable

The card gives the team something to test. It also makes clear what the first version must not do.

Check the project card before development

Give the card to an employee who did not write it. Ask them to work through one ordinary example and one with missing or conflicting information. They should be able to find the documents, identify the discrepancies and know when to stop without an answer. If they need the author's verbal explanation, the card is incomplete. We fix it before connecting any systems.

Our article on an AI-agent task brief explains the structure in more detail.

4. Build and integration follow the checks

We prepare checked examples, test a wrong or incomplete document and review the cost and access rules. A prototype stays separate from production systems until the owner approves the behaviour. The team then receives the instructions and practises the route in the interface it will use.

The final step is adoption in daily work. A system is not complete because a demo answered once. We need a responsible owner, a review path and a way to see failures.

A similar route in a training guide

An AI Masters training guide (in Russian) describes a similar route: map repeatable work, pilot several processes, create reusable working templates and then measure the result. AI Masters is an education project by Serge Shima, a Majento co-founder, and the figures in the guide belong to that training programme.

To see how our team builds agents with memory and integrations, look at Iva, an open-source AI assistant in Telegram.

Continue the route

Read about team AI training · See AI implementation · Map a business automation project

Reference for evaluating the example

The NIST AI Risk Management Framework is further reading for the risk and evaluation questions in this example. It is a useful checklist for the project card: data, permissions, the review method and the fallback.

Discuss a workflow on Telegram