Dean Shabi
All work

Otty · 2026

An AI that applies to jobs for you, only where you said yes

Otty is a career agent you talk to on WhatsApp. It researches roles, decides which ones fit and applies under your name, but only within rules you've approved. I founded the company and built the product.

Role
Founder · product and engineering
Stack
TypeScript, Postgres, AI SDK, Cloud Run, OpenTelemetry
A hand holding a phone over a café table, beside a cup of coffee and a folder of paper

How it works

  1. 1

    Candidate goals

  2. 2

    Job research

  3. 3

    Permission check

  4. 4

    Submission

  5. 5

    Application tracking

One agent talks to the candidate and research workers assess jobs. A separate service checks permission before anything is submitted.

Results

From roles judged to interviews, first four weeks

Each bar and the figure beside it is a share of all roles judged. The figure under each stage name is the share kept from the stage above. The agent turned down most roles, and every application it sent went through the candidate's rules first.

  1. Roles judged
    100%
  2. Chosen to apply22% of the stage above
    22%
  3. Applications submitted48% of the stage above
    11%
  4. Submission confirmed57% of the stage above
    6.2%
  5. Employer responses37% of the stage above
    2.3%
  6. Interviews40% of the stage above
    0.9%

Otty production data, first four weeks.

In its first four weeks, Otty chose to apply to 22% of the roles it judged. 21% of the applications it sent got an employer response, and 8.5% led to an interview.

Key decisions

  1. 01

    The agent judges fit. Code grants permission.

    Research workers can assess a role but can't apply to it. Every application goes through a separate path that checks the candidate's approved CV, preferences, limits and pause setting at the moment of submission.

  2. 02

    Keep facts and memory apart

    Approved facts and permissions live in the database. Conversation memory can shape a reply but can never authorise an action. Each application's status is rebuilt from an event log, so a late email can't roll it back.

  3. 03

    Find where the cost actually goes

    Tracing whole user journeys showed a prompt cache that never hit, every tool loaded on every call and database reads running one after another. Fixing those cut cost per turn 5× and time to first response from 6.3 s to about 0.9 s.

  4. 04

    Cap the paid work

    Finding jobs is cheap, so the search is wide. Paying a model to review them is expensive, so I capped that budget. The system never retries a failed paid call, so one bug can't spend the money twice.

Have a machine learning system that has to hold up in production? I'd like to hear about it.

Book a 30-minute call