At work, I conduct discovery with clients to identify AI transformation opportunities. These conversations produce a large amount of information about processes, systems, exceptions, and the work people do around them. Turning it into a coherent current-state view has remained largely manual.

SMEs rarely describe an operation in the order a process map requires. The normal workflow, an exception, and an approval rule may emerge across separate conversations. Access restrictions, escalation paths, performance measures, and missing baselines can sit outside the walkthrough entirely.

I designed Discovery Facilitator around this bottleneck: structure raw discovery material into a shared knowledge base, preserve the evidence behind individual facts, and generate current-state views that make both the knowns and the gaps easier to review.

The working prototype accepts written process accounts and structures them into an engagement knowledge base, connecting processes and steps with people, systems, pain points, exceptions, and metrics. Follow-up captures can update existing records as understanding develops across conversations.

The workspace brings capture and the resulting knowledge together so the facilitator can inspect what was extracted. It generates current-state swim-lane views with system interactions, escalation points, and gap callouts. Because these views use the stored knowledge, corrections carry through to subsequent outputs.

• Stated
• Inferred
• Estimated
• Gap

Evidence states apply to individual attributes, allowing a record to contain both confirmed information and unresolved details. Knowing that an approval step exists does not establish its financial threshold. A metric can be relevant without a known current value.

When new information resolves a gap, the current-state view reflects the newer evidence while retaining its history. Missing information should remain visible rather than being hallucinated by the model.

In a synthetic insurance-claims scenario, the first extraction captured all 15 systems but did not consistently store their access restrictions in the dedicated field. Some restrictions survived only in descriptive text. API availability, for example, does not mean an operations team has authorization to automate an action.

I added explicit handling for system access constraints and decision authority across extraction, storage, and the knowledge surface. This preserved the constraints that determine what is actually feasible for solution design.

An early diagram connected consecutive activities into a single sequence. Different exception-resolution routes looked like steps every case had to pass through, while recurring reporting appeared as another transaction stage.

I revised the flow model to represent conditional branches, return paths, ongoing oversight, and unresolved ownership. The generator also requires supporting excerpts for proposed connections and ownership assignments; unsupported ownership can remain unassigned.

A shortened label, assigned lane, or arrow can introduce a claim about how an operation works. Each needs to remain grounded in the captured information.

I tested extraction and current-state generation against several synthetic operational narratives, including claims intake, payment exceptions, and vendor invoices. Evaluation focused on preserving the details that could change a future solution: access restrictions, decision authority, exception routing, operational metrics, unsupported assumptions, and unresolved information.

The current prototype focuses on narrative capture, structured knowledge, and current-state generation. The broader product design extends into:

1. Documents & screenshots
2. Adaptive discovery
3. Opportunity assessment
4. Solution fit
5. Transformation roadmap

The solution-fit framework is intentionally technology-agnostic. It considers process change, rules, conventional automation, generative AI, and agentic workflows rather than treating AI as the default answer.

I built jobpilot to make my own job search more manageable. Every application meant reconstructing the same experience, deciding which parts mattered for a particular role, and checking whether the wording still reflected what I had actually done. Relevant details were spread across resume versions and notes, so the process often started over from scratch.

A resume is selective by design. It leaves out projects, decisions, responsibilities, and context that may be highly relevant to another opportunity. Giving a language model a resume and a job description helps with wording, but it leaves important questions unanswered: which experience supports this requirement? Is context missing? Why was a strong example left out? Has the wording become more confident than the evidence allows?

I wanted a system that could maintain that context over time, use it deliberately, and let me understand and correct how it arrived at an output.

jobpilot builds a career knowledge graph from resumes and notes. Roles, projects, skills, and achievements are stored as connected facts with references to their source material. Follow-up questions help fill gaps that may improve future applications.

That knowledge supports two main workflows:

1. Job discovery

   Collect openings directly from company job boards, apply constraints such as location and seniority, and rank opportunities against the experience recorded in the graph.

2. Resume generation

   For a selected role, choose relevant evidence, turn that selection into resume language, and produce a one-page document. A selection log shows what was included and omitted; source references make individual bullets inspectable.

I designed and built the knowledge model, discovery workflow, generation pipeline, interface, and evaluation approach.

1. Separate evidence selection from writing

   The system first decides which facts are relevant, then asks the model to phrase that selection. Users can inspect both the content decision and the resulting language.

2. Make omissions visible

   A resume can be factually accurate and still leave out the strongest experience. Showing why something was dropped distinguishes missing evidence, low relevance, and page-length constraints.

3. Keep hard constraints deterministic

   Search constraints such as geography run in code rather than relying on model interpretation. Preferences are versioned so past recommendations can be understood against the criteria that applied at the time.

4. Keep submission with the user

   jobpilot helps find opportunities and prepare materials. The user reviews the output and applies through the employer’s site.

In one recorded discovery run, the pipeline processed 9,822 openings across 57 company boards in 16.8 seconds.

The larger dataset let me test whether the product decisions held up against real job-board data, beyond small controlled examples.

jobpilot started as a personal workflow problem and became a testbed for evidence, relevance, determinism, and user control. A strong AI product needs to make clear what information shaped an answer, where hard constraints should override model judgment, and where the user should retain control.

Building it end to end let me test those decisions against real data rather than treating them as design principles in isolation.

I designed an AI-driven operating model for reconciliation across multiple systems, focusing on manual break matching and approval routing. The work started with understanding where effort accumulated in the existing process, then identifying where automation could reduce manual work without losing the controls needed for review and approval.

The proposed model identified potential workload savings equivalent to 7–9 FTE, but the design problem extended beyond matching records. The target state also needed to define how unresolved breaks were handled, where decision authority remained with people, what evidence an approver would need, and how the audit trail would be preserved.

My contribution centered on discovery, workflow design, and the proposed operating model.

I worked with account teams to understand current processes, pain points, systems, and data, then used that context to shape the future-state agentic workflow. The design covered automated break matching and approval routing, including the boundaries between agent-owned activity and human sign-off.

Approval routing was part of the workflow design from the beginning. Completing an automated step does not necessarily mean an item is ready to close.

That boundary is especially important in financial operations, where technical capability and decision authority are not the same thing.

A reviewer needs enough context to understand:

• How an item reached its current state
• What evidence was used
• What the system is recommending
• What they are being asked to approve

Defining where that evidence lives made the human-review step part of the operating model.

The proposal made the intended division of work explicit: agent responsibilities, human sign-off, exception handling, and the location of the audit trail. Those details created a basis for implementation discussions.

The next step would be a bounded pilot against the existing workflow. I would evaluate four areas:

The key question is whether the combined agent + human workflow performs better than the current operation.

This project sharpened how I approach enterprise AI solution design. The proposed agent behavior, approval process, exception handling, audit trail, and operating model needed to be designed together.

It also reinforced the importance of separating the business case from deployment evidence. The workload estimate gives the organization a reason to investigate the opportunity, but only a pilot could help determine whether the system earns the right to operate in production.