Ana Stanojević
AI Engineer — PhD EPFL
AI systems built for real-world constraints.
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
- Split single runtime into queue + controller; persist Opportunity and ExecutionContext.
- Add retrieval API behind planner; backfill memory schema (facts, drafts, outcomes).
- Introduce policy engine as single gate for submit/hold/escalate; route all terminals through it.
- Stub browser executor behind feature flag; ship DOM extract + apply-path detect before full automation.
- Wire outcome tracker to strategy ranker for closed-loop adaptation.
- IN BUILD
- DEMO SOON
INPUT CV · job description · preferences
outcomes → ranking / thresholds / retries
feedback loop → queue ranking · policy tuning · escalation behavior
Contact
Simple contact—pick a topic and write a short note.
Preview
Edit the draft if needed, then add your email address.
Sent. I’ll reply soon.
Draft email appears here.