Skip to main content
Back to Blog
AI/MLCloud ComputingProject Management
13 May 20267 min readUpdated 13 May 2026

AI Determines if Your Meeting Should Be an Email Instead

Introduction Recall the last calendar invite you received that had no agenda, 12 participants, and was titled "Quick Sync." We've all encountered meetings that seemed unnecessar...

AI Determines if Your Meeting Should Be an Email Instead

Introduction

Recall the last calendar invite you received that had no agenda, 12 participants, and was titled "Quick Sync." We've all encountered meetings that seemed unnecessary, better suited as an email. Imagine if your workflow could offer a subtle reminder to only schedule meetings when necessary. Instead of automatically arranging a meeting, you could outline the task's details, allowing AI to draft an email or prepare a meeting agenda for your calendar invites. Emails and meeting agendas require different levels of detail and, ultimately, different large language models (LLMs) to craft them.

Illustration for: Recall the last calendar invit...

This exact solution has been developed using a new Inference Router feature, a policy-driven system that aligns incoming requests with the best model based on task complexity, eliminating the need for hardcoded logic. Here’s a guide on how this "Could have been an email" router works and how to create a custom router.

Key Takeaways

  • The Inference Router semantically directs prompts to suitable models based on customized instructions, with a user-friendly setup process.
  • Integrated directly into the inference pipeline, users can make requests normally while the router manages the workflow.
  • The system identifies task nature and routes requests to either a faster, cost-effective model for emails or a more complex model for meeting agendas. This setup can extend beyond meetings to handle support tickets, code reviews, legal documents, etc.

Illustration for: - The Inference Router semanti...

How the Router Works

Traditional LLM inference involves sending a request to one model and receiving a response, with quality depending on the model's capability. LLM routers act as an intermediary layer, directing your request to the most appropriate model, optimizing for speed, cost, or specific tasks. This allows teams to use a single endpoint for diverse needs while ensuring optimal cost and speed.

In this setup, two tasks are created. The write_email task utilizes a fast, affordable model for drafting simple emails. The write_meeting_agenda task uses a more sophisticated model to generate detailed meeting plans. The router reads the task description and routes it to the appropriate model. If the task is simple, it generates an email; if complex, it creates a meeting agenda, with the routing decision serving as the verdict.

Step 1 — Building the Router

To build a router, access your cloud account and navigate to the router creation page. Assign a unique name and description to your router, which also acts as a routing prompt for task identification. Define the tasks with names, descriptions, and model pools. You can use pre-configured tasks or create custom tasks that specify models and ranking criteria.

Once tasks are set, specify fallback models to handle unmatched requests, ensuring every input receives a response. For automation, create the router with a POST request, passing task definitions and models as a JSON body.

Step 2 — Building the App

Integrating the router into an application is straightforward, as it replaces direct model calls. Use the Chat Completions endpoint, including the router's name prefixed with router: in the model field. Authentication remains consistent, requiring a Model Access Key. The user’s input becomes the message content, which the router processes.

import requests

def meeting_or_email(user_input):
    url = "https://inference.do-ai.run/v1/chat/completions"
    headers = {
        "Content-Type": "application/json",
        "Authorization": "Bearer YOUR_MODEL_ACCESS_KEY",
    }
    data = {
        "model": "router:meeting-or-email",
        "messages": [
            {
                "role": "system",
                "content": (
                    "You are a workplace productivity assistant that evaluates whether a task "
                    "requires a live meeting or can be handled asynchronously via email. "
                    "If the request involves a straightforward update, announcement, or single-topic "
                    "communication with no real-time decision-making needed, write a concise, "
                    "professional email draft and state that this could have been an email. "
                    "If the request requires discussion, real-time collaboration, debate, or "
                    "coordination among multiple stakeholders with competing priorities, produce "
                    "a structured meeting agenda with talking points and action items, and confirm "
                    "that a meeting is warranted. Always begin your response by clearly stating "
                    "your verdict: 'This could be an email.' or 'This warrants a meeting.'"
                ),
            },
            {
                "role": "user",
                "content": user_input,
            }
        ]
    }

![Illustration for: def meetingoremail(userinput):...](https://storage.googleapis.com/xfinit-blogs-scraper-assets-664708921442/blog-assets/images/7f325d4d-cb31-4b17-b662-452d25ab153d.jpg)

    response = requests.post(url, headers=headers, json=data)
    response_body = response.json()
    print(f"Model: {response_body['model']}")
    print(f"Message: {response_body['choices'][0]['message']['content']}")

The response indicates which model was selected, with tasks classified automatically by the router.

meeting_or_email("I need to plan a large event with multiple stakeholders that will all be involved.")
Output
Model: anthropic-claude-opus-4.7
Message: This warrants a meeting.

Coordinating a large event with multiple stakeholders involves competing priorities, real-time negotiation of responsibilities, and collaborative decision-making that simply cannot be handled efficiently via email threads. Below is a structured agenda to make the meeting productive.

For simpler tasks, the system efficiently routes to a model that drafts an email.

meeting_or_email("I have some metrics I want to share with my team.")
Output
Model: llama3.3-70b-instruct
Message: This could be an email.

Here's a draft email you could send to your team:

Subject: Update on Key Metrics

Dear Team,
...

Step 3 — Deploying to App Platform

Prior to deployment, it's beneficial to validate the router's functionality using the Inference Router playground. This allows you to compare responses and confirm the accuracy of task descriptions. After deployment, the Analyze tab provides a live view of router performance, with metrics on requests, token usage, model match rate, and fallback rate. This data aids in refining task descriptions and model pools over time.

Conclusion

The meeting app exemplifies the power of not choosing a specific model for each request but rather describing conditions for model suitability, letting the router enforce these at runtime. This approach optimizes resource use and reshapes the design process for complex tasks. The method extends beyond meetings and emails to various scenarios like customer support or legal document classification.