From a repetitive workflow to an AI application.

The workflow involved job discovery, company research, resume analysis, tailoring, reviewing, scoring, and proposal writing.

Putting all of these responsibilities into one agent would make the agent's context increasingly large and its behavior harder to control.

I separated the workflow into specialized agents, each responsible for a specific task.

This made responsibilities explicit and allowed individual stages to have their own context, prompts, and evaluation criteria.

The architecture became more complex. More agents meant more orchestration, more LLM calls, and more places where failures could occur.

In return, the workflow became easier to reason about, debug, evaluate, and extend.

Company research can be expensive and repetitive.

If every resume-tailoring workflow independently researched the same company, the system would repeatedly spend time and tokens collecting information that had already been discovered.

I treated company research as reusable application data rather than temporary context for a single AI run.

Research results could be persisted and reused by later workflows targeting the same company.

Persisting research introduces data-modeling and freshness problems.

The system now needs to decide when existing research is still useful and when it should be refreshed.

The benefit is that expensive research becomes a reusable asset instead of being regenerated for every application.

LLM calls and other AI operations are long-running, failure-prone, and dependent on external services.

Application state — jobs, companies, resumes, applications, and workflow status — needs to remain consistent even when an AI execution fails or is retried.

I separated the persistent application state from the execution of AI workflows.

The application owns the state and workflow status, while AI execution operates as a processing layer that reads the required context and produces outputs.

This separation requires more explicit state management.

The system needs to track execution status, retries, intermediate results, and failures instead of relying on a single request-response flow.

In return, AI jobs can be retried or changed independently without coupling the application's core state to a particular LLM execution.

Once a workflow contains multiple AI calls, it becomes difficult to understand why a single application is slow or expensive.

A successful output alone doesn't tell me whether the workflow is efficient.

I tracked metrics such as token usage, latency, and estimated cost across AI executions.

This gave me visibility into which stages consumed the most resources and provided data for later optimization.

Instrumentation adds implementation effort and produces additional data that needs to be stored and interpreted.

However, without these measurements, optimization would largely depend on intuition.

For an AI application, execution metrics become part of understanding the system itself.

Not every step in the workflow depends on the previous one.

Several pieces of company or job information can sometimes be collected independently. Running each operation sequentially would make the total workflow unnecessarily slow.

I parallelized independent operations where their inputs did not depend on one another. Instead of:

A → B → C → D

some parts of the workflow could become:

      ┌→ B ─┐
A ────┼→ C ─┼→ D
      └→ E ─┘

This reduced unnecessary waiting between independent operations.

Parallel execution increases concurrency and therefore increases the number of things that can fail at the same time.

It also requires more careful handling of rate limits, retries, resource usage, and result synchronization.

The trade-off was worthwhile for independent, latency-sensitive operations where sequential execution provided no additional correctness.

Job data came from external sources, and the same position could appear multiple times across fetches or sources.

Without deduplication, the system could create duplicate records, repeat downstream processing, and waste AI calls.

I introduced deduplication at the data-ingestion layer so that the rest of the workflow could operate on a cleaner set of jobs.

This prevented duplicate data from propagating into company research, analysis, and resume-tailoring stages.

Deduplication requires defining what actually makes two job records the “same” job.

A rule that is too strict can leave duplicates; a rule that is too aggressive can incorrectly merge different positions.

The system therefore needs a stable identity strategy and a balance between deduplication accuracy and implementation complexity.