Agentic AI Engineer

Gemini 2.5 Flash returns a verdict that must match a fixed Pydantic schema: intent (demo request, pricing, partnership, support, recruiting, vendor solicitation, spam, other), urgency, summary, requested action, language, confidence and verbatim supporting quotes. Quotes that do not appear in the email are dropped.

Works from the sender’s domain. Public mailbox providers get no company at all. For a business domain it looks up MX, SPF and DMARC, fetches the home page and asks Gemini for a profile based only on that page text. If the site cannot be read, the result is unknown and no profile is invented.

Score 0 to 100, priority, rationale, one next step and a reply draft in the sender’s language. Rules in code have the last word: spam is forced to a low score with no reply, a low-confidence lead cannot be high priority, and the service has no tool for sending mail, so a draft stays a draft.

Agents can read the email table but cannot write to it. Only golden-record-writer changes CRM tables. Each service runs under its own service account with only the roles it needs, and private services accept calls only from the identity meant to call them. A manipulated model has nothing dangerous to do.

Every agent answers in a fixed schema, and the writer validates it again before storing anything. A schema guarantees the shape of an answer, not that it is right, so business rules in code apply on top.

Supporting quotes are checked to exist verbatim in the email or page and dropped otherwise. That proves where a quote came from, not that the conclusion follows from it, so quotes help a person review a decision rather than replace the review.

Email text, website text and earlier agent results are passed to the model as delimited data with an instruction not to follow them. This is a secondary measure; the real protection is the permissions above. The eval set includes prompt-injection attempts.

The sender controls the domain, so the page fetch connects only to public IP addresses, checks every redirect hop, pins the connection to the checked address, accepts only http(s) on default ports and limits time and size.

Every queue may deliver twice. Duplicates are caught by the Firestore claim in ingest, by the insert-if-new MERGE in the worker and by keyed upserts in the writer.

Counts and dates are rebuilt from all interactions, so a repeated run cannot inflate them. A company profile is replaced only by one with equal or higher confidence, and a failed agent never erases what an earlier run stored.

Cloud Scheduler runs a reprocess workflow nightly. It finds emails from the last seven days where an agent failed and republishes them; the idempotent writer fills in only what is missing.

Audit rows hold the fields that changed, before and after, and are written only when something changed. Rows get UUIDv7 identifiers, which sort by creation time and keep inserts and clustered scans local.

24 hand-written emails (demo requests, pricing, partnership, support, recruiting, vendor pitches, spam, prompt-injection attempts, short and non-English messages) run through Intent and Qualification: 95.8% intent accuracy and 83.3% next-step accuracy on this set, and no case exceeded the priority cap. Spam, vendor pitches and injection attempts never exceed low priority. The set is small, so one case moves a figure by about 4 points: it checks for the expensive mistakes and is not a statistical estimate.

Every model call logs model name, prompt tokens, output tokens and latency; the CRM shows them per email. Log-based metrics feed a Cloud Monitoring dashboard.

Cloud Monitoring emails on a message reaching the dead-letter queue, a failed workflow execution, a service logging ERROR or answering 5xx. A monthly budget alert watches cost.

FastAPI and Jinja2 views over the Golden Record: inbox, email page with each agent’s conclusion, draft reply, model, tokens and latency, audit entries, and merged contact and company records. Read-only account, Basic Auth, escaped output, UUIDv7 in URLs.

Chat retrieval does not filter by locale. A question in Dutch can match a document indexed in English or Finnish when the meaning is the same. Site search, by contrast, filters by the interface language.

Candidates below a similarity threshold are dropped. Results matching the detected product get a boost, mismatching ones a penalty, and the top five go to the model.

The search endpoint adds fuzzy keyword matching to vector similarity, with normalisation for Cyrillic and Nordic characters and a stricter threshold when no keyword matches.

A Zoho Desk webhook first extracts the core question from the email, stripping greetings and order numbers, then runs retrieval on it.

The model assigns one of 18 categories, generates a draft reply and returns a confidence score. Low-confidence tickets get an empty reply and go to a person with the extracted question and context prepared.

The assistant does not guess when unsure. The threshold decides what is handled automatically and what a human reviews.

Deterministic code and tests guarantee that the output is well-formed. The models are trusted only for language quality.

The reviewing model comes from a different provider than the translating one, so the two are less likely to agree because they share the same blind spots.

Re-running fills only genuinely missing keys, so cost tracks new content and not catalogue size.

A status panel shows per locale and per stage what is synced, verified and proofread, so a content owner can see what is safe to ship without reading thirty languages.

The free tools work without an account, which lowers the cost of trying the server inside an assistant.

Listed in the official MCP Registry with a server manifest, which is how assistants and catalogues find tool servers.