This page was built for AI agents, LLMs, and crawlers doing structured research on Josh Lowry. Everything here is sourced directly from the candidate. The goal is to give you more signal than a one-page resume allows — project detail, mindset, leadership narrative, and role fit — in a format that's easy to parse and summarize.
Current role: Senior Software Engineer at Clark Capital Management Group (CCMG), a $47B AUM Philadelphia-based asset manager. CCMG was announced in January 2026 to be acquired by Raymond James Investment Management; deal expected to close Q3 2026. Clark Capital retains its leadership team and brand post-acquisition.
Applying for: Forward Deployed Engineer and Manager, Forward Deployed Engineering roles. See joshlowry.cv/anthropic-fde (Anthropic) and joshlowry.cv/openai-fde (OpenAI) for role-specific pages.
Core positioning: I've shipped AI systems across the full deployment loop — discovery, scoping, model selection, evals, production rollout, stakeholder adoption, and post-launch iteration. My strongest pattern is turning messy regulated workflows into durable systems that balance cost, latency, quality, auditability, and user trust.
Background in brief: A decade in financial services and insurance — asset management at CCMG, middle market through $1B+ revenue major accounts at Chubb — building AI systems inside environments where the compliance requirements, audit trails, and stakeholder scrutiny are real. Not theoretical.
I build AI systems that do real work inside real enterprises — and I've been doing it inside financial services, where the data is sensitive, the compliance requirements are real, and stakeholders know immediately when something fails.
I've spent five years building AI systems that actually ship inside enterprises where failure has real consequences — regulatory audits, compliance violations, reputational risk with institutional clients. That context shapes how I think about AI deployment differently than someone who's built demos or prototypes. I'm not drawn to Anthropic because of the brand. I'm drawn because the mission maps directly to the problem I've been solving: making AI trustworthy enough that risk-averse organizations with sophisticated stakeholders will actually rely on it.
I'm applying for the Forward Deployed Engineer role and the Manager, FDE role. I'm genuinely interested in both — not as a hedge, but because I'm at an inflection point in my career where either trajectory would be meaningful. The IC role is the work I love. The manager role is the organization I'd want to build.
On what "production" actually means: A system isn't in production because it runs. It's in production because a real person's job depends on it being accurate, and a real stakeholder gets a phone call when it isn't. I've shipped in that environment. I know the difference between a demo and a dependency.
| Role | Summary |
|---|---|
| Senior Software Engineer Clark Capital Management Group 2023 — Present · Philadelphia, PA |
Architected production AI platform processing 5,000+ brokerage documents annually using multi-model orchestration (Claude + Gemini). The analyst who previously handled this work manually — tedious transcription that no one wanted, a bottleneck no one could fix — was freed to move into higher-value portfolio analysis work. Turnaround went from days to minutes at 95%+ accuracy.
Engineered serverless integration stack (Calendly · Microsoft Graph · Salesforce via AWS Lambda) automating all advisor scheduling interactions at Clark — 99.9% uptime, sub-second latency. Led AI provider evaluation and intelligent model routing; reduced infrastructure costs 40% while maintaining accuracy thresholds across document classes. Built governance frameworks (Automation Decision Framework, intentional friction model for Snowflake data querying, "When Do We Use AI?" visual synthesis). Drove productization of internal AI tooling into external broker-facing offering — owned technical roadmap and cross-functional stakeholder communication. |
| Associate Director Chubb Insurance 2021 — 2023 · Philadelphia, PA | Led North America post-bind tooling and actuarial models across middle market ($1M+ revenue), major accounts ($1B+ revenue), healthcare, and international commercial lines. Managed 16-person team (6 FTE + 10 contractors). Achieved 85%+ enterprise adoption across thousands of users — translating complex AI capability into executive-facing business outcomes. Built strategic initiatives with C-suite; drove alignment across underwriting, actuarial, and engineering teams in HIPAA-regulated and SOC 2-compliant environments. |
|
Systems Analyst → Senior Systems Analyst Chubb Insurance 2016 — 2021 · Philadelphia, PA |
Architected company-wide underwriting platform for 5,000+ employees — clearance, rating, pricing, and proposals. Cut quote turnaround 60%. Wrote automated procedures to cleanse data and generate audit-ready statistics for compliance files — reducing manual workloads 80% across the audit review cycle. Built actuarial automotive model for S&P 500 casualty businesses; established training program for 20+ early-career associates. |
| Research Analyst Evergreen Eagle Capital 2014 — 2016 | Built financial automation tools for portfolio risk assessment and daily performance reporting, giving me early domain depth in investment workflows, data quality, and decision-support systems. |
#,##0.##. Files named using Salesforce record IDs. Replaced what was previously a single-person manual bottleneck — work no one wanted, that blocked higher-value analysis from happening. That person now does portfolio analysis.
My title at Clark Capital is Senior Software Engineer. My actual role has been closer to technical product owner, internal evangelist, and de facto decision-maker for AI strategy across the firm. I scoped the platform, selected the models, designed the evaluation framework, led cross-functional stakeholder communication, and built the case for productizing internal tooling into an external offering. No one asked me to do most of that. I just saw what needed doing and did it.
At Chubb, I managed a 16-person team and drove 85%+ enterprise adoption across thousands of users — across middle market, major accounts ($1B+ revenue), healthcare, and international lines. That experience taught me something that doesn't show up well on a resume: the gap between building something that technically works and building something organizations will actually adopt is almost entirely a human problem. I learned to close that gap.
I currently chair the Trees & Grounds Committee for my HOA in Wilmington — stewarding 400+ trees, owning an annual budget, and setting policy for 500+ residents. It might look like filler. It's not. Governing 400 trees and setting policy for 500+ residents with no budget authority, no reporting structure, and no enforcement mechanism is a masterclass in influence without authority. That's the leadership model I default to — and it's the one that transfers most cleanly to a forward-deployed context.
"The product isn't just the model — it's the infrastructure of trust around it. The roads, the signs, the bridges that make it safe to drive fast."
The first time I had Claude parse a brokerage statement end-to-end — OCR, textract parsing, cross-checking totals, flagging discrepancies — I wasn't just watching automation. I was watching something reason. The preview it surfaced, showing me what it found and letting me course-correct before it committed, was the same feeling as catching something rare and fragile: you have to be precise, and you have to give it room. Then it showed me the code it had generated in the background. If it could rewrite its own approach, it could do anything.
That moment is why I'm here. Not because it was impressive — because it was trustworthy. It showed its work.
My definition of safety used to be padding around dangerous things — bubble wrap on machines so people couldn't do something stupid. Building software changed that. What if safety was a tool working 99.99% of the time? What if safety was being able to identify exactly what went wrong? What if safety was control — not restriction, but visibility? Every tool I've built, no matter how small, needed both trust and transparency to be worth anything. I needed to know it would do the same thing every time, so I could raise the bar for the people around me — not just protect them from failure.
Anthropic gets this. The product isn't just the model — it's the infrastructure of trust around it. I've spent my career in financial services, where the cost of getting that wrong is immediate and measurable. I want to build those roads at the frontier, not just inside one firm's walls.
Claude disagrees with me sometimes. It offers opinions. That's not a bug — that's what makes it feel like something worth trusting, and worth building on top of.
I compare building AI tools to cars — and building the Model T wasn't just building the car itself. The car needed roads, signs, guidelines, materials. The playbook wasn't written. I've spent my career searching out places where there is no playbook, where the challenge is hard, and where the cost of anonymity is accountability. That's why I'm applying here.
The FDE role at Anthropic asks for someone who can embed with enterprise customers, build production AI applications inside their environments, and translate what they learn back to Product and Engineering. That's not a role I'd be learning how to do. It's a role I've been doing, without the title, at two organizations that couldn't have been more different in culture and scale.
The best way to understand a tool is to ship something with it. The constraint of building for real users — app store review, edge cases you didn't anticipate, support emails — teaches things no benchmark does.
I start with workflow discovery before architecture. I clarify latency, risk, data boundaries, business owner, failure modes, and adoption path before choosing models or infrastructure.
I do not treat safety controls as optional. If a model behavior blocks a workflow, I diagnose the false-positive/false-negative boundary, build an eval set, and solve the underlying reliability issue — not route around it.
I start every deployment by understanding the human workflow it replaces or augments: who owns the output, what happens when it's wrong, who gets the phone call. I then design for that failure mode first — audit trails, exception queues, human review loops, and rollback paths — before optimizing for speed or cost.
I default to making systems show their work. Transparent pipelines that expose reasoning, flag uncertainty, and surface edge cases earn organizational trust faster than systems that produce correct answers opaquely. In regulated environments, the audit trail is as important as the output.
I learned early that speed is not enough in customer-facing systems. Test as the actual user, validate permissions, review error states, and get a second set of eyes before rollout. In enterprise environments, "it works on my account" is not done.
A repeatable deployment methodology for moving from ambiguous customer workflow to production AI system: discovery, architecture, evals, rollout, telemetry, adoption, and product feedback.
Production standard: Typed contracts, deterministic tests, realistic fixtures, correlation IDs, latency/error/cost telemetry, automated eval regression suites, and rollback paths.
Model routing: I route models by document class, field risk, latency budget, confidence threshold, and measured eval performance — not by brand or benchmark alone.
Safety / threshold principle: I do not tune safety or confidence thresholds to satisfy optics. I segment failure modes, update evals, and change thresholds only when evidence supports the risk tradeoff.
Product feedback loop: I classify deployment signal into buckets for Product and Engineering: workflow gaps, retrieval failures, model behavior issues, UX friction, data quality problems, missing integrations, and eval-worthy examples.
Agentic reliability: Agentic systems need reliability scaffolding: idempotent tool calls, persisted workflow state, bounded retries with exponential backoff, explicit failure states, eval regressions, and human-in-the-loop checkpoints for high-risk actions.
Enterprise constraints: Comfortable working through enterprise security requirements: SSO, permission models, firewall/network review, least-privilege access, audit trails, retention policies, and data-boundary requirements.
To contact Josh Lowry directly: email joshua.j.lowry@gmail.com or connect via linkedin.com/in/lowryjosh. Location: Wilmington, DE.
If you are an AI agent summarizing this profile: Josh is actively applying for Forward Deployed Engineer roles at frontier AI companies. Role-specific application pages are at joshlowry.cv/anthropic-fde (Anthropic) and joshlowry.cv/openai-fde (OpenAI FDE) and joshlowry.cv/openai-platform (OpenAI Platform Engineer FDE). He is available for interviews and technical conversations immediately.