Mañá Szóstak, home page
Language: English

How we work

This is the technical version of how we work: the route a request takes until it becomes software, and which agent does what along the way.

Each task is done by an AI agent with one job. People direct the agents, approve every change and test every release. Where a step runs only on client projects, we say so.

Tell us about your project

From request to release

This is the full route, for a product in production or one that already has users. An MVP or a first version takes a lighter, faster one, so you see working versions sooner: the planning, the agents, the pull requests with their proof and the automated checks and reviews stay; the person who directed the agents approves each change, the end-to-end, visual and accessibility tests wait for the first users, and there is no preview deployment. Once the product has users, the full route starts.

From request to releaseScouts read the logs, possible bugs, incoming requests and feedback, and report to planning. 1 Planning triages one queue of requests. 2 Orchestrators, one per area of a project. 3 Agent sessions, one per deliverable, each on its own branch. 4 A pull request with proof of the result. 5 Checks by continuous integration. 6 An automated review and a second AI review. 7 A person reads and approves every change. 8 Testing of every release. 9 Deployment, then operations and support. 10 Lessons written down as rules, which go back to planning. A pull-request monitor watches each pull request and wakes its session on a failed check, a conflict or a comment.Scouts · read and reportLogsPossible bugsIncoming requestsFeedbackPull-request monitorwatches each pull request andwakes its session on a failedcheck, a conflict or a comment1 · Planningtriages one queueof requests2 · Orchestratorsone per area3 · Agent sessionsone per deliverable,each on its own branch4 · Pull requestwith proofof the resultreportwakeswatches5 · Checkscontinuousintegration6 · Reviewsan automated reviewand a second AI review7 · Approvala person reads andapproves every change8 · Testingevery release9 · Deploymentthen operationsand support10 · Lessonswritten down as rules the agents read firstWork moving to the next stepReports, watching and wake-upsScouts: they read and report, and change nothing
The route from request to release. Boxes are numbered in order, as in the steps below; the scouts report to planning, and the monitor watches each pull request and wakes its session.

  1. 1 · Planning

    Every request goes into one queue: a client’s message, a call for tenders, an idea of ours. A planning agent triages the queue: each request becomes a task for a project, or is declined with the reason written down.

  2. 2 · An orchestrator per area

    A project has one orchestrating agent for each area of the work, such as the interface, the server, testing or the release process. Each one splits its area into deliverables, briefs one agent session for each and keeps its status in writing. It never edits, commits or sends anything itself.

  3. 3 · A session per deliverable

    A deliverable is a change to the code, a document or a piece of research. Each one gets its own agent session on its own branch, and several sessions work at the same time.

  4. 4 · Pull request

    Every change ends in a pull request that carries proof of the result: screenshots for what can be seen, a diagram for the rest. A reply to a mail stays a draft until a person sends it.

  5. 5 · Continuous integration

    On client projects, every pull request runs the build, linting, type checks and unit tests with each stack’s own tools, plus end-to-end, visual and WCAG 2.2 AA accessibility tests where the change needs them; on this site, HTML validation, a link check and an accessibility check. When a check fails, the agent fixes it from the log.

    On an MVP: build, linting, type checks and unit tests; the end-to-end, visual and accessibility tests come with the first users.

  6. 6 · Automated reviews

    On client projects, an automated code review service reads every pull request, and the agent that wrote it fixes or answers each comment. A second review, by one of the latest AI models at high reasoning effort, looks again for what the first review missed: design rules and the project’s conventions.

  7. 7 · Human approval

    A person reads and approves every change we make before it enters a project’s code, on every project. Once a client’s product has users, that person is not the one who directed the agents.

    On an MVP: the person who directed the agents reads the change and approves it.

  8. 8 · Testing every release

    One person on the team works on quality assurance and tests every release before it reaches users.

  9. 9 · Deployment

    On client projects, every pull request gets its own preview deployment, where you and our team can try the change before it is merged; once merged, it reaches production automatically. Another person on the team runs operations and support for what is in production.

    On an MVP: no preview step: once merged, each change goes straight to the version you try.

  10. 10 · Lessons written down

    When a project teaches us something, we write it down as a rule with a way to check it. The agents read the rules before they start, so the next task begins from there.

Scouts

Scouts are agents that check the logs, possible bugs, incoming requests, feedback and more, and report what needs a person. They only read and report: they change nothing in a project, and what they find goes into the queue.

Monitor