At a high level, the service behaves like a scheduled email-processing pipeline.

Each run starts by fetching recent emails from Outlook through Microsoft Graph. Those emails are normalized into one internal shape, classified for relevance, then classified again for application status if they are relevant. The result is persisted in Airtable as a processed-email record, and when the email clearly supports a job-level action, the system either creates or updates the corresponding job record. After the run finishes, a concise Telegram summary is sent with the run outcome.

The full flow looks like this:

Microsoft Graph inbox
  -> normalize email
  -> classify relevance
  -> classify status
  -> persist processed email record in Airtable
  -> resolve whether a job record should be created, updated, or skipped
  -> apply the job record action
  -> mark email as read (best effort)
  -> send Telegram run summary

Under the surface, the service is split into a few practical layers:

• Microsoft Graph for mailbox retrieval and read-state updates
• OpenAI structured outputs for classification and job-record resolution
• Airtable for processing state, run state, and job records
• Telegram for operational summaries

That combination kept the project lightweight while still making it useful in practice.