Assistants built around your team’s own work.

We automate the work your team repeats.

How it works

  1. Something comes in to your own tools: an email, a ticket, a new build or a changed page.
  2. The agent reads your sources (tickets, the knowledge base, the app, the manuals) and works inside your own tools.
  3. Where you allow it, it finishes the task itself: it replies and resolves the ticket, runs the test or updates the page. Everywhere else, it hands the task to a person, with what it found.

Every step is logged with its sources. It starts read-only; writing is a switch you control.

What the agent does with each task, step by step. The three cases below show it on a helpdesk, a test suite and a manual.

Ticket resolver

Dunmarrow, a wholesale distributor’s IT helpdesk: an email comes in, and the AI agent solves it or tells IT what to do. Fictional customer.

The problem: The same questions reach the desk every week, and each one waits in the queue until someone has time.

What it does, in three steps

  1. 1 An email arrives and becomes a ticket A user emails the helpdesk, and the email becomes a ticket.
  2. 2 Checks past tickets and the knowledge base The agent checks past tickets and the knowledge base and finds the same problem, already solved.
  3. 3 Known fix: resolved. Needs IT: alerted. Known fix: it replies and resolves the ticket; needs IT: it alerts the helpdesk team with what to do.
Sample data: Dunmarrow is a fictional company. Its emails, tickets and knowledge base were written for this demo. The demo is scripted and sped up in places.
Tested with
Tickets it never saw while it was built, with every answer graded against the sources it cited, and tickets that look familiar but need a person, which it must not answer on its own.
Built from
An index of the knowledge base and past tickets, a list of verified fixes that may go out on their own, an alert that hands the rest to the helpdesk team with what it found, and a helpdesk connection with the rights you set.

End-to-end testing assistant

Benchwick, a software company: before a release, the assistant tests its booking app like a customer and reports what broke. Fictional customer.

The problem: Before every release, someone clicks through the same flows by hand, and a broken step slips through when time is short.

What it does, in three steps

  1. 1 A new build, four test scenarios A new build is on staging, and the assistant queues four test scenarios in two browsers.
  2. 2 Books like a customer, checks each step It books a workshop like a customer, checks every step, and finds the discount applied twice.
  3. 3 A report with screenshot and suggested fix It writes the report: 3 passed, 1 failed, with a screenshot, expected and actual, and a suggested fix.
Sample data: Benchwick is a fictional software company, and the app under test is a demo app. The test run is scripted and sped up in places.
Tested with
A test copy of the app with faults planted in it on purpose, which it must find, and flows that work, which it must pass without false alarms.
Built from
A browser it drives step by step, test scenarios written in plain language, checks against what the screen shows, and a report with screenshots.

Documentation assistant

Spokeline, a business-software vendor: a gap in its manual becomes a new section, drafted from the app and approved by a person. Fictional customer.

The problem: The app changes every month, and the manual still describes screens that no longer exist.

What it does, in three steps

  1. 1 The manual misses: cancelling a booking The gap list shows what the manual never covered, and a person picks one: cancelling a booking.
  2. 2 Walks the app, drafts with screenshots It walks through the feature in the app, like a person, and drafts the section with fresh screenshots.
  3. 3 A person approves, the manual updates A person approves the draft, and the manual gets the new section: 4.3.1 Cancelling a booking.
Sample data: Spokeline is a fictional business app, and Larkmoor Cycles a fictional bike shop that uses it. The demo is scripted and sped up in places.
Tested with
Machine checks on every draft before a person reads it: the steps match the screens, every button name is on screen, and every picture has a caption that matches it.
Built from
A browser session with a step ledger, a section writer, checks against the screen, and a diff with undo.

How our automations work

Built around the tools your team already uses, with a person in charge of what matters.

What it does
  • Works inside your own tools: the helpdesk, the web app, the manual
  • Acts on its own only where you allow it; everywhere else, it hands the task to a person with what it found
  • Keeps a log of every step, with its sources and screenshots
  • Starts read only; writing is a switch you control
Handoff

A person stays in charge. Whatever it may not finish on its own, it hands to the right person on your team with what it found, and a new manual section waits in a review step until a person approves it.

Tested with

Every build comes with its own tests: cases from your own history that it never saw while it was built, faults planted on purpose that it must catch, and a written list of failures with the guard for each.

Built from

Your knowledge base, tickets, app and manual as its sources, a browser it can drive, connections with the rights you grant, and a review step with undo. You own the data and the off switch.

Tell us which work repeats

Describe the tickets, test runs or manuals that take your team’s time, and what a person should keep deciding.

Ask for a demo

We reply within 2 working days, in English or Croatian.