Building on Gemini models

Job matching involves large inputs — a full CV, several postings, a candidate’s application history. Being able to hold all of it at once removes a lot of chunking machinery and the errors that come with it.

It is particularly useful for comparison tasks. Evaluating one CV against ten postings in a single call, with everything visible, produces more consistent relative judgements than ten independent calls ever will.

Consistency is the underrated part. Ten independent scoring calls drift against each other because nothing anchors them to a common scale, where one call ranking ten postings produces an ordering that is internally coherent even if the absolute numbers are arbitrary.

CVs arrive as PDFs with columns, tables, graphics and occasionally scanned pages. A text-extraction pipeline mangles exactly those cases, and the mangling is silent.

Passing the document directly to a model that reads it visually handles layouts that defeat extraction. Verify the result against your structured profile rather than trusting it, but as a parsing path for awkward documents it is markedly better than the alternative.

Use it as a fallback rather than the default path. Text extraction is far cheaper and correct for the majority of documents, so the sensible design extracts first, detects the failure signs — out-of-order sections, missing dates, a suspiciously short result — and escalates only those to the expensive route.

• Multi-column layouts that linearise badly
• Tables of skills or dates
• Scanned or image-based pages
• Anything where extracted text arrives out of reading order

Every token in the window costs money and latency, and relevance still degrades when the important detail is buried among a hundred thousand tokens of loosely related material. "Put everything in" is a design that works until it quietly stops.

Retrieval remains the right approach at scale: select what matters and send that. Use the large window to be generous with what you include, not as a substitute for deciding what is relevant.

The failure is gradual rather than obvious, which is what makes it dangerous. Nothing errors when the context grows; results simply get slightly worse and slightly slower, and the cause is invisible unless someone is comparing against a smaller, curated prompt.

Function calling and schema-constrained responses work the way you would expect, and the same rules apply as anywhere: describe tools by their effect, keep required parameters few, and make error returns instructive.

Define output schemas for every extraction step rather than parsing prose. This is the single change that most reduces incidents in an extraction-heavy pipeline, regardless of provider.

Validate the domain as well as the shape. A schema-valid result with a salary of zero, a date in the future or a location outside the allowed set has satisfied the constraint and not the requirement, and catching that at the boundary is far cheaper than discovering it in a ranking.

Provider capabilities and prices move, and an agent wired directly to one SDK is expensive to move later. Express tools and results in your own types and keep the provider behind one adapter.

This also makes routing possible: multimodal parsing to one provider, cheap classification to another, hard judgement to a third. That flexibility is only available if the seam exists from the start.

Record which provider and model produced each stored result. Without that, a change in behaviour after a model update is indistinguishable from a change in the market, and re-scoring for consistency becomes guesswork rather than a query.