Skip to content
Erik Tagirov
Menu

AI projects

AI workflows built around real work.

I turn workflow problems into local AI applications and prototypes, taking responsibility for product architecture, requirements and verification.
My work includes a packaged Windows CV application and a product-management assistant in development.

Independent project · Packaged Windows build

Tailored CV Local

Generating a relevant CV was only part of the problem. Every claim also needed a traceable basis in the career profile.

I designed a local-first Windows workflow that separates vacancy analysis, content planning, generation, claim validation, human editing and PDF export. Significant generated statements are required to link back to source facts.

My work covered product architecture, requirements, model-provider interfaces, privacy requirements and verification. Implementation used AI coding agents; I directed the work and reviewed the resulting behaviour.

What was produced

A packaged Windows application and release evidence, including verification with a real local model.

Independent project. No commercial rollout or external user scale is claimed; live verification did not cover every provider path or installation scenario.

Product-work assistant · In development

From discussions to work ready for review

I started by using AI to process stakeholder discussions into decisions, requirements and open questions. I am developing that workflow into a modular assistant; question routing and broader follow-up automation are planned extensions.

Not every sentence is a requirement

A discussion can contain a decision, a proposal and an unanswered question in the same minute. The follow-up needs to keep those differences clear.

Illustrative example · fixed sample text · no live AI

Select a candidate to trace it to the discussion. Selection is not approval.

A fictional product discussion

  1. S1Product leadLinked source

    Let's show the current payout status in the first release. Email notifications can wait.

  2. S2SupportLinked source

    Users need to know whether they should wait or contact us.

  3. S3EngineeringLinked source

    We still need to agree how to present manual-review cases.

  4. S4Product leadLinked source

    Yes, keep email notifications out of release one. I'll review the proposed status wording before we commit it.

Review candidates

  1. D1 / Decision candidateSelected

    Keep email notifications out of release one

    The discussion sets status visibility as the first-release focus and explicitly defers email notifications.

    Review noteCheck that the person speaking had the authority to make this scope decision.

  2. R1 / Requirement candidate

    Explain whether the user should wait or seek help

    Support describes a user need. The exact wording and acceptance criteria still need to be agreed.

    Review noteThis is not yet an approved user story.

  3. Q1 / Open question

    How should manual-review cases be presented?

    Engineering raises an unresolved question. The discussion does not contain an answer.

    Review noteKeep the question open instead of inventing a requirement.

A proposed requirement, a confirmed decision and an unanswered question should not become the same kind of task.

What is working, and what comes next

The meeting-processing workflow and the wider assistant are at different stages.

The workflow is more than a model call

I’m exploring how to separate input preparation, task routing, specialised modules and the model layer. The aim is to carry the right context into each task and keep draft outputs available for review.

Planned architecture

  1. Input preparation
  2. Task routing
  3. Specialised modules

    Model adapters: local / cloud

  4. Draft outputs
  5. Human review
Architecture direction for the assistant; not all components are implemented.

Preparation can be automated. Responsibility cannot.

The assistant can prepare material for review. Priorities, scope, trade-offs, release decisions and compliance acceptance stay with the responsible people.