Sure — [quick origin: I've been building software for ~X years, came up through Y]. For the last stretch I've been working independently, building AI agent systems — [a couple of concrete examples]. What I kept running into is that the interesting part was never getting a model to do something impressive; it was getting it reliable enough that someone would actually depend on it. So I ended up spending most of my time on the unglamorous half — grounding, verification, making sure the thing isn't confidently wrong. [One concrete: e.g. I built a headcount-planning agent where the lift came from verification, not a better model.] And honestly that's what pulls me toward something like this — I want to go deep on one hard problem with a real team, in a domain where reliability actually matters, instead of skimming across a lot of projects. Finance is about the purest version of that.

Right now I'm working independently — building AI agent systems, mostly [what you're actually doing]. I've genuinely enjoyed it and learned an enormous amount. But the honest answer is that independent work makes you broad and shallow: you're constantly context-switching, and you rarely get to go deep enough on one problem to really solve it — or live with it in production long enough to learn what actually breaks. I want the opposite of that. One hard problem, one team, real data, something that compounds instead of ending when the engagement does. [Optional and very human: and frankly, I miss having colleagues.] So this isn't me looking for a gig — it's me wanting to go deep somewhere the work matters.

Honestly, it's the trust problem that pulls me in. I've spent my time building AI systems, and the hardest, most interesting version of that is a domain where being wrong actually costs something — where you can't just ship a plausible-looking answer. Finance is that domain in its purest form: a number's either right and traceable, or it's a real problem. I like working where the truth is checkable and it matters. [Add a personal thread — e.g. always liked the rigor of numbers / grew up around a family business / did X that got me into it / I like that finance is the one place AI has to actually be correct, not just impressive.]

What hooked me wasn't the flashy demos — it was the gap between a demo and something you'd actually trust in production. Getting a model to look smart is easy; getting it to be reliable enough that a real team leans on it is the hard, fun engineering problem, and that's the part I kept gravitating toward. I like building the boring, load-bearing parts — the grounding, the checks — that make the magic actually usable. [Make it yours — e.g. the first agent I built that actually worked / the moment I realized I cared more about reliability than novelty / a specific project that clicked for me.]

Fair — and I'd rather just be straight about it. I'm not going to walk in knowing your close calendar, your materiality thresholds, or how your category P&Ls are actually structured. That's real, and it's why I think my first month is mostly listening rather than building. What I'd lean on is that I've learned domains by embedding in them before — and the finance concepts themselves aren't really the hard part. The hard part is knowing which details matter to your team, and that only comes from sitting with them through a close. What I'd bring on day one is the other half: knowing how to make an AI system trustworthy enough for a domain like this. I'd much rather be honest that I'll need to learn the finance than oversell it and get something wrong in front of your CFO.

I've spent my time building AI agents where the hard part is trust — grounding, verification, getting fabrication to zero. FP&A is the purest version of that problem: a domain where a wrong number is unacceptable. eBay is a data-rich marketplace where finance is under real pressure to do more with the same team — take-rate precision, ad-revenue forecasting, category discipline. That's exactly where an internal AI-tools builder pays for themselves. I want to build the tools, not just advise on them.

I'd start where high-frequency, high-toil, and verifiable-output overlap — monthly variance commentary and self-serve data retrieval — not autonomous forecasting. Those are hated, done constantly, and every output is checkable against the ledger, so I can prove accuracy and build trust before touching the number the board sees. Win the close first, earn the forecast later.

You never ask them to trust it — you make it show its work. Every number grounds to a source row; there's an independent check that would fail if it were wrong, not a self-reported confidence score; the query and driver are one click away; and it drafts while the analyst approves. Autonomy is earned per-workflow after accuracy is demonstrated, and everything's reproducible for audit. Trust comes from traceability, not from the model being impressive.

The most relevant one: I prototyped a headcount-planning agent — Req Room — against an eBay-style req workflow. It hit ~89% against a ~47% baseline. The lift didn't come from a better model; it came from decomposing the task and adding verification so the agent couldn't confidently produce a wrong answer. That's the same architecture I'd bring to a variance or forecasting tool here.

A confident, wrong number landing in a board deck or guidance model — because that's not a bug, it's an eroded-trust event that sets the whole program back a year. The subtle version is silent failure: the tool fabricates in the one field nobody checked. My whole approach is built around that — verify with checks that would fail, keep a human approving, and instrument for the errors you can't see. I'd rather ship a narrower tool I can vouch for than a flashy one I can't.

Business outcomes first: days off the monthly close, forecast-accuracy delta, analyst hours redeployed from wrangling to analysis. Then adoption — are analysts choosing to use it unprompted — and a hard quality bar: the tool's error rate has to be at or below a human's on the same task, measured, not asserted. If adoption's high but I can't prove accuracy, that's a red flag, not a win.

Buy the commodity — the planning platform, the ERP. Build where eBay's proprietary data and specific workflows are the moat, which is exactly the AI layer on top. A vendor add-on can't know your category P&L structure or take-rate drivers. So: don't rebuild Anaplan; do build the grounded agents that sit on top of it.

I embed and shadow before I build — sit through a close, watch where the hours actually go. I ship small and let their reaction steer, because they know materiality and the audit constraints better than I ever will. My job is to translate their pain into tools, not to hand them tech and hope. The best signal I'm doing it right is when an analyst asks for the next feature unprompted.

The monthly flux mostly runs itself — the agent drafts, an analyst reviews exceptions. Reforecasts become continuous instead of quarterly fire drills. The analyst's job shifts from producing the number to interrogating it — more business partnering, less spreadsheet plumbing. But every step of that is gated on trust earned in the prior step; I wouldn't skip to autonomy.

Two things. First, I'm a translator — I came up as a designer, so I start from the human and the workflow, not the tech. I can sit with a team, find what actually hurts, and turn it into something they'll use, not just a clever demo. Second, I'm relentless about reliability — the unglamorous parts, grounding and verification and making sure a tool isn't confidently wrong, are the parts I actually enjoy, and they're exactly what makes people trust it enough to depend on it. Put together: I build things people adopt, in a way finance can trust.

Honest one: I've worked solo for a few years, so my default is to just go build it myself — head down, figure it out. It's efficient, but I can get pretty far down a path before I pull anyone in for a gut-check. I've been countering it deliberately — shipping smaller, showing rough versions instead of polished ones, forcing feedback earlier. And honestly it's part of why I want to be in-house: I do better work when someone can push back on me early, not just at the end.

Early on I built something that was genuinely good technically — [the project] — and it basically didn't get used. That lesson landed hard: I'd optimized for how impressive it was instead of how it fit into their actual day. It's where my whole approach came from — now I embed first, ship small, and treat adoption as the real metric, not whether the model is clever. So the failure wasn't wasted; it's the reason my later builds actually stuck.

Three things line up. One — I build the tools, I don't just advise; you'd get someone who ships. Two — the thing I'm best at, making AI trustworthy enough to depend on, is the whole game in finance, where a wrong number actually costs something. Three — I'm not looking for a gig; I want to go deep on one hard problem with a team, in-house, for the long run. The honest version: I'd be genuinely excited to do this job, not just be employed by it.

Depth over breadth. Solo work gives me a lot of variety, but I rarely get deep enough on one problem to really solve it, or stick around long enough to see it through. I want the opposite — one hard problem, a real team, real data, something that compounds instead of ending when a project does — in a domain where the work matters and correctness is real. This role is basically that list.

I want it — especially from someone who knows the domain better than me. If an analyst tells me the tool is wrong, that's the most valuable feedback I get; it's far cheaper to hear it in week one than in a board deck. My habit is to ship small so we're arguing over a real artifact, not a hypothetical. I treat them as the authority on materiality and process, and me as the person who makes their judgment scale. [Optional: a time a stakeholder pushed back and it made the build better.]

Becoming the person a finance org trusts to turn “we should use AI for this” into something that actually works — something they'd stake a number on. Deep expertise in this specific intersection of AI and finance, rather than spread thin. If it grows into leading a small function or setting how the team builds, great — but the core is being the trusted builder, not chasing a title. And I'd rather earn that here over years than hop for it.

Honestly, not at all — I'm genuinely comfortable working on my own. I've worked with overseas and distributed teams before, so the time-zone spread is familiar territory, not something I'd be figuring out for the first time. I actually do some of my best work when I've got the autonomy to just run with something. The way I keep it from feeling isolated: I over-communicate async — clear written updates so nobody's ever guessing what I'm working on — and I protect a bit of overlap with each side, mornings with the India team and a window with you, for the things that are just better live. [Add a specific example — an overseas/distributed team or project you ran, and how you stayed in sync across the time gap.] So genuinely, the setup reads as a plus for me, not a concern.

I don't have a hard number in mind yet — honestly, I'd want to understand the scope and level first. What range is the role budgeted at? [If pressed: give a range, tie it to scope, and note you'd want to look at the whole package. Never a single precise figure.]