Ana Stanojević

AI Engineer — PhD EPFL

AI systems built for real-world constraints.

Contact Current build

About

PhD at EPFL with research experience across Huawei, IBM, and Google.

Now focused on building real-world AI systems.

Expected-value decision runtime

Bounded Job Application Agent

Typical agents maximize activity. This system maximizes expected value under uncertainty, cost, and execution risk.

Low-confidence opportunities are intentionally skipped. Quality over quantity is a design choice.

Architecture

Intake → ranking → bounded decision runtime → execution → human submit

Control & adaptation

Decision loop selects next action: research / prepare application / queue / skip / escalate

Learning: outcomes update ranking, thresholds, retry policy

Example run (real flow)

120 jobs → 18 filtered → 6 shortlisted → 2 prepared → 1 escalated → 1 submitted

  • stateful runtime
  • bounded autonomy
  • uncertainty-aware
  • tool-grounded execution
  • policy-gated actions
  • human final submit
Implementation plan · behavior · policy · migration

Reference behavior map for the agent system; decisions ship incrementally behind one policy surface.

System behaviors

  • strategy service — async crawlers/feeds, normalize/dedupe, rank, enqueue.
  • queue manager — opportunity queue, lease/dequeue, priority, cross-job budget hints.
  • runtime controller — per-job state machine, iteration budget, routes agents, terminal decisions.
  • memory store + retrieval layer — structured facts, snippets, drafts, traces, outcomes, company records; similarity / filters for planner and writer.
  • policy engine — submission gates, confidence thresholds, escalation rules, hold-for-approval.
  • browser executor — instrumented navigation, DOM extraction, apply-path classification.
  • application executor — draft/export/email packet, optional form fill, submit only via policy.
  • outcome tracker — ingest replies/silence; emit events for policy and strategy.

Core state objects

  • Opportunity — source id, normalized posting, rank score, queue position, dedupe key.
  • ExecutionContext — job id, budget remaining, policy snapshot, apply-path enum, trace id.
  • EvidenceBundle — CV facts, retrieved snippets, prior successful patterns per requirement cluster.
  • DraftRevision — versioned draft, critic verdicts, grounding map.
  • DecisionRecord — terminal action, confidence, policy version, human-approval flag.
  • OutcomeEvent — channel, label (reply/reject/silence/interview), timestamps for adaptation.
  • PolicyConfig — thresholds, allowed auto-submit surfaces, company blocklist, rate limits.

Execution policies & safety

  • No submit without passing critic grounding; high-risk paths require human approval.
  • Rate limits and per-source caps; explicit blocklist for companies/domains.
  • Budget caps per job and per rolling window; starvation limits for low-priority queue items.
  • Browser session isolation, credential vaulting, audit log of actions.
  • Outcome feedback updates ranking weights and retrieval priors—versioned policy rollouts.

Migration from simpler build

  1. Split single runtime into queue + controller; persist Opportunity and ExecutionContext.
  2. Add retrieval API behind planner; backfill memory schema (facts, drafts, outcomes).
  3. Introduce policy engine as single gate for submit/hold/escalate; route all terminals through it.
  4. Stub browser executor behind feature flag; ship DOM extract + apply-path detect before full automation.
  5. Wire outcome tracker to strategy ranker for closed-loop adaptation.

VIEW REPO →

  • IN BUILD
  • DEMO SOON

Contact

Simple contact—pick a topic and write a short note.

Draft email appears here.