Meeting recordings to notes & tasks

I constrain the model and then verify its output. The Information Extractor gets the invite list and must return, for each item, an owner email from that list, a verbatim transcript quote, and a confidence score. An IF node then checks the schema, confirms the owner is an invitee, and confirms the quote actually appears in the transcript with a simple string match in a Code node. Anything that fails, or is below the confidence threshold, goes to the host through a Wait-for-form approval rather than straight to the project tool. Over time I track how often owners delete or edit tasks, and use those examples to tune the prompt and threshold.

A Webhook node receives the upload event. A Code node verifies the signature, and a Postgres ledger lookup on the recording ID drops duplicates. An HTTP Request node sends a signed audio URL to a speech-to-text API with speaker labels. A Wait node then pauses until the provider calls the resume webhook. A Code node cleans and chunks the transcript, and a Calendar API call fetches the title and invite list. The Information Extractor, using a chat model through Vercel AI Gateway, returns the summary, decisions and action items. An IF node validates the output, and anything uncertain goes to host review through a Wait form. Loop Over Items creates tasks with deterministic keys. Gmail emails only the invitees, the ledger is marked completed, and an Error Trigger workflow alerts on failures.

I key it on recording_id, a primary key with a unique constraint, so concurrent duplicate events collide at the database. Other columns: calendar_event_id, status (received, transcribing, extracted, in_review, tasks_created, emailed, completed, failed), the n8n execution ID, the transcription job ID, the model used, created and updated timestamps, and an error message. Task IDs go in a child table keyed on recording_id plus item_index, with the external task ID and the last payload hash. That table is what turns reruns into updates. I add an email_sent_at column so the email step can check before sending. I don't store the full transcript there. Large or sensitive text belongs in storage with a retention policy, not in a status table.

Retry-on-fail on the node retries transient errors first. If retries run out, the execution fails and the Error Trigger workflow posts to Slack with the execution link. The ledger shows tasks_created was never reached, and the child table already holds external IDs for items 0 to 2. When someone re-executes, the loop checks each deterministic key: the first three exist, so they are updated or skipped, and only items 3 and 4 are created. The email and the completed status come only after all tasks succeed, so attendees never get a summary with missing links. Recovery is just a rerun, because every write is idempotent.

The recipient list is never taken from model output. A Code node right before the Gmail node builds the recipients from the Calendar API invite list fetched in step 3. It intersects that with any proposed list and throws an error if anything falls outside it. Recipients go in To or BCC exactly as computed, with no free-text fields mapped from the transcript. I normalise case and trim whitespace before comparing. I also log the final recipient list in the ledger for audit. If the calendar lookup failed or returned nothing, the workflow does not send to the host's guess. It routes to review or fails loudly. Defence in depth: the allowlist sits in deterministic code, not in a prompt instruction.

Idempotency at every write. The webhook first looks up the recording ID in a Postgres ledger and stops if it is already processing or done. Each task gets a deterministic key, recording ID plus item index, stored with the project tool's returned task ID, so a rerun updates the existing task instead of creating a new one. The ledger has separate flags for tasks created and email sent, and the Gmail node only runs if the email flag is false. With that in place, per-node retry-on-fail and re-executing a failed run from the executions list are both safe, which matters because transcription and project tool APIs do fail intermittently.

Practically, it gives me one credential in n8n instead of several provider keys. The chat model sub-node is OpenAI-compatible with the base URL set to the gateway, so switching from anthropic/claude-sonnet-4.5 to openai/gpt-5 is a model-name change, not a credential or node change. I can configure a fallback model so a provider outage does not fail every meeting, and spend is tracked in one place, which lets me report cost per meeting. It also reduces risk: provider keys never sit in the n8n credential store or in exported workflows. The trade-off is one more dependency in the path, so the error workflow covers gateway failures too.

I configure the Webhook node to keep the raw body, because most providers sign the exact bytes and re-serialised JSON won't match. A Code node reads the signature and timestamp headers. It recomputes the HMAC with the shared secret, held in a credential and not hard-coded, and compares the two values in constant time. It also rejects timestamps outside a short tolerance window to block replays. If verification fails, the workflow responds with an error and stops before touching the ledger or any API. For storage-bucket events, I use whatever authentication the provider offers, such as signed notifications or a secret token. Signature checks prove authenticity. The ledger check is what handles duplicates.

A read-then-insert check has a race: both executions can read 'not found' before either writes. Instead, I do an atomic insert, INSERT the recording_id with status received ON CONFLICT DO NOTHING, and check whether a row was actually inserted. Only the execution whose insert succeeded continues. The other ends quietly with a 200 response, so the sender stops retrying. This works in queue mode with many workers too, because the database enforces uniqueness rather than n8n. If a later stage fails, a rerun finds the existing row and resumes based on its status instead of being dropped as a duplicate.

I give the Wait node a time limit. When it expires, the execution continues down a timeout branch. That branch calls the provider's job-status endpoint with the stored job ID. If the job finished, it fetches the transcript and carries on. If it failed or is still stuck, the ledger is marked failed and the Error Trigger or a Slack alert notifies the owner. I store the transcription job ID in the ledger so a later rerun can check status rather than pay to transcribe again. I also make sure the callback URL n8n generates for the execution is the one passed to the provider, and that the URL is reachable from outside.

A Code node splits the cleaned transcript into chunks on speaker turns or topic breaks, with a small overlap so an action item isn't cut in half. Each chunk goes through the Information Extractor for candidate action items with quotes. A final reduce step merges the summaries and de-duplicates items that appear in overlapping chunks, matching on owner plus a similar description or quote. Item indexes must be assigned after this merge, so the deterministic keys stay stable across reruns. Chunking costs more calls but improves recall, because models skip details in very long inputs. Each item's quote should also be checked against the original transcript text.

Speaker labels give separation, not identity. I give the model the invite list with names and emails, plus cues from the transcript such as self-introductions or people addressing each other by name. I ask it to name an owner only when the evidence is explicit, like 'Priya, can you send the deck' followed by agreement. Then the IF node checks that the owner email is in the invite list. When ownership is ambiguous, the item goes to host review with no owner rather than a guessed one. Some recording platforms supply participant names per audio track, which helps a lot. A confident wrong assignment is worse than an unassigned task, so I tune for precision.

The Wait node is set to resume on a form submission. The host gets a link showing the draft summary, the decisions, and each action item with its owner, due date, supporting quote and confidence. The flagged items are highlighted. The host can edit text and pick owners from the invitee list only, so even manual edits respect the allowlist, and can delete items before approving. On submit, the execution resumes, and the edited data is validated again before tasks are created. If the time limit passes, the timeout branch sends a reminder and ends the run with the ledger set to in_review_expired. Nothing is auto-approved, because silence is not consent.

I'd start from assumptions the interviewer and I agree on: meetings per day, the peak-hour share, average length, and action items per meeting. Most wall-clock time is transcription, and the Wait node removes that from worker occupancy, so active n8n work per meeting is short: a few API calls plus one or more model calls per chunk. Peak concurrency is roughly peak arrivals per minute times active processing minutes. I'd size queue-mode workers from that, with headroom. The real limits are usually external: transcription quotas, gateway and model rate limits, project tool API limits, and Gmail sending limits. So I'd load-test with real recordings, read the execution timings, and add backoff rather than guess.

First, data minimisation: use short-lived signed audio URLs, and don't keep the transcript longer than needed. Second, execution logs: n8n can save full execution data, including transcripts, so I'd limit or prune saved data for successful runs and restrict who can view executions. Third, access: least-privilege credentials for the project tool, Gmail and the calendar, scoped to what the workflow needs. Fourth, vendors: check the retention and training policies of the transcription provider and the models behind the gateway, and choose providers that meet our requirements. Fifth, legal: record with consent and follow the applicable rules, such as India's DPDP Act, for purpose and retention. Finally, attendees only ever see what the invite list allows.

Index-based keys break if the item list changes between runs. A rerun of the model might reorder items, or the host might delete item 2, shifting everything after it. Then a rerun overwrites the wrong task. To avoid that, I freeze the item list once it is validated or approved. I store the items with their indexes in the ledger child table, and reruns read from there instead of calling the model again. Another option is to derive the key from a hash of normalised content, but small wording changes alter the hash. So the rule I'd use is: extract once, persist, assign the index, and never regenerate the list for an already-processed recording unless someone explicitly asks.

That's prompt injection through the transcript, and the design assumes model output is untrusted. The model only returns structured JSON. It cannot send email or create tasks itself, because it has no tools. Recipients come only from the calendar invite list in deterministic code. Owners must match invitee emails, or the IF node rejects them. Email addresses appearing in the summary text don't affect routing. I'd also tell the system prompt to treat the transcript as data, and escape or strip anything that looks like instructions in the email body. So the worst case is odd text in a summary that a human can catch, never data leaking to an outsider.

I'd build a labelled set of real or consented sample meetings, covering short and long ones, many speakers, accents, and meetings with no actions. For each, a human writes the expected action items and owners. Metrics: precision and recall on action items, owner accuracy, due-date accuracy, and the rate of items without a valid quote. A separate n8n test workflow, or the same one pointed at a test project and test inbox, runs the set for each prompt or model change. Before go-live I'd run it in shadow mode, generating drafts for hosts without creating tasks. Host edits in the review form become new evaluation data after launch.

They would if email had no idempotency of its own. Re-sending an email can't be undone, so I treat the send as a guarded step. Before sending, check email_sent_at in the ledger. After sending, write it immediately, along with the returned message ID. There's still a small window where the send succeeds and the write fails. To narrow it, I keep the ledger update directly after Gmail, give it retry-on-fail, and on rerun check the sent folder for that subject or message ID before sending again. True exactly-once delivery isn't possible over email, so the honest answer is at most a rare duplicate, checked and logged.

Queue mode makes sense once executions compete for one instance: peak bursts after the top of the hour, many concurrent loops, or a need to scale without UI slowdowns. In queue mode the main instance receives triggers and webhooks and puts executions in Redis, and separate workers pick them up. Postgres is the shared database. The workflow design mostly stays the same, but it must be stateless across workers. That is why idempotency lives in the Postgres ledger, not in memory or static data. Waiting executions are stored and resumed by whichever worker is free. I'd add webhook processors if inbound volume grows, and watch queue depth as the key scaling signal.

n8n stores credentials encrypted and nodes reference them, so secrets never appear in workflow JSON or exports. This workflow needs a few credentials: the AI Gateway API key, the transcription API key, the calendar and Gmail OAuth, the project tool token, Postgres, Slack, and the webhook signing secret. The gateway helps here, because no individual model provider keys live in n8n, just one AI Gateway key that can be rotated and spend-tracked. On self-hosted n8n, I protect the encryption key, back it up safely, and keep it the same across main and worker instances. I also avoid printing secrets or tokens in Code node output, because execution logs would capture them.

I choose a primary model by testing extraction quality on real transcripts, for example anthropic/claude-sonnet-4.5, and configure a fallback in the gateway for outages or rate limits. Different models phrase things differently, so consistency comes from the contract, not the model. The Information Extractor enforces a schema, the IF node validates it, and quotes are checked against the transcript. I record which model actually produced each result in the ledger, so quality problems can be traced. Before allowing a model as a fallback, I run the same evaluation set against it. If it falls short on owner accuracy, it's better to wait and retry than fall back silently.

Only partly. A self-reported confidence is not a calibrated probability. It helps, but it's not enough alone. So the routing rule combines it with deterministic checks: the schema is valid, the owner is in the invite list, the quote is actually found in the transcript, and the due date parses. Any failed check sends the item to review, whatever the confidence. I'd set the confidence threshold from data: label a sample of meetings, compare the model's scores with correctness, and pick a cut-off that keeps wrong auto-created tasks acceptably low. Then I'd watch the review rate and host corrections over time to adjust it.

Per stage: the ledger status counts, and especially recordings stuck in transcribing or in_review. Also failure counts by node from the execution logs, and alert volume from the Error Trigger. Quality signals: the share of items routed to review, host edit and delete rates, and how many tasks get reassigned later in the project tool. Cost and latency: time from upload to email, gateway spend per meeting (the gateway tracks spend), and transcription minutes. Capacity: queue depth and worker utilisation in queue mode. A daily Schedule-triggered workflow can query the ledger and post a summary to Slack, so slow drift gets noticed, not only hard failures.

The model extracts the phrase and the quote, but I don't let it do date maths blindly. I pass the meeting start time and the host's timezone from the calendar event as context, and ask for an ISO date plus the original phrase. A Code node then checks the date: it must be after the meeting, inside a sensible horizon, and consistent with the phrase where that can be parsed. Ambiguous phrases like 'soon' or 'end of quarter' without context leave the due date empty, or route the item to review. Storing the raw phrase lets the host correct it in the form, and keeps the project tool from showing invented deadlines.

Without the invite list, there are no allowed owners or recipients, so the workflow must not guess. Matching should use a reliable link if the recording platform provides one, such as a meeting or event ID. Otherwise, match on organiser plus a time window. For recurring meetings, I fetch the specific instance, because attendees can differ per occurrence. If there's no match or several, the ledger is marked needs_review and only the uploader or host gets a form to choose the event or confirm attendees. Every downstream check depends on this one lookup being right, so failing safe here protects everything else.

Most cost is transcription minutes and model tokens. Dedupe with the ledger first, so retries don't transcribe or extract twice. Persist the transcript reference and the extracted items, so reruns resume from the failed step instead of repeating paid work. Clean the transcript before extraction, which cuts tokens. Use a smaller model for chunk-level extraction and a stronger one only for the final merge, if evaluation supports it. Gateway spend tracking shows cost per model, and I'd log usage per recording in the ledger. Skipping very short or empty recordings also helps. I wouldn't cut cost by removing review or validation, because a wrong task is more expensive than tokens.

The Digital Personal Data Protection Act, 2023 applies, because transcripts contain personal data. In practice: have a clear purpose and notice for recording and processing, get consent, and announce in meetings that notes are generated. Keep only what's needed and delete transcripts when the purpose is done. Know which processors handle the data, here the transcription provider, the model providers behind the gateway, and the project tool, and have suitable agreements in place. Support access and erasure requests by being able to find a person's data by recording ID. I'd confirm the exact obligations with legal rather than assume, especially for cross-border processing.

The rerun should be safe, not destructive. I store a hash of the payload we last sent. On rerun, if our new payload matches the stored hash, skip the update entirely. If it differs, for example because the host corrected an item, update only the fields the workflow owns, such as the description and source link, and leave status, comments and manual reassignment alone. Better still, compare the tool's current values with what we last wrote, and only change fields nobody has touched since. The project tool becomes the source of truth once a person starts working there. The workflow's job is to create tasks correctly, not to keep fighting people's edits.

Step 4 is a single, bounded transformation: transcript in, schema-shaped JSON out. The Information Extractor is built for that. You define the attributes or schema, and it returns structured output with no tool calls or memory. An AI Agent decides its own steps and calls tools, which adds unpredictability, extra cost, and a larger prompt-injection risk. Here, the model should have no ability to act. Every side effect, like creating tasks or sending email, stays in deterministic nodes behind validation. I'd consider an agent only for an optional chat feature over past meetings, and even then with read-only tools.

Yes, once it grows. Execute Workflow lets me separate ingestion (webhook, signature check, ledger), transcription, extraction and validation, review, and delivery (tasks and email). Each part gets clear input and output items and can be tested alone with pinned data. Splitting also lets a 'reprocess from stage X' admin workflow call just the delivery sub-workflow for a recording, using the stored items. The trade-off is some indirection when debugging, because the execution is spread across several logs. Sub-workflows are useful for reuse too: the delivery part could serve another source, such as manually written notes, without copying nodes.

I'd keep one extraction pipeline and branch at delivery. A team setting, looked up from the meeting organiser or calendar, says which tool to use. A Switch node routes to the right app node, such as Jira, Asana or Linear, or to an HTTP Request for tools without a node. Each branch maps the same internal task schema (title, owner email, due date, quote, source link) to that tool's fields, and resolves owner emails to tool user IDs. The ledger child table stores the tool name with the external ID, so updates go to the right place. If an owner has no account in that tool, the item stays unassigned and the host is told.

Both are valid outcomes, not errors. If the transcription returns empty or near-empty text, I mark the ledger no_content and optionally tell the host, without calling the model. If extraction returns zero action items, the IF node should accept an empty list as schema-valid. The summary email still goes out with 'no action items recorded', and the ledger is marked completed. The prompt should state that an empty list is acceptable, because models pushed to find items will invent them. Treating 'nothing found' as a normal path also keeps the error workflow from paging someone about routine meetings.

1. AThe model's confidence score
2. BA recording-ID check against a Postgres ledgerCorrect answer
3. CThe Wait node's timeout setting
4. DGmail's thread grouping

Why: Step 1 checks the recording ID against a Postgres ledger, so a repeated event is dropped before any paid work happens.

1. AThe calendar event's invite listCorrect answer
2. BEveryone in the company directory
3. CThe speech-to-text provider's speaker labels
4. DNames the model detects in the transcript

Why: Step 3 fetches the invite list from the Calendar API and uses it as the only allowed owners and recipients.

1. AA Code node with a sleep loop
2. BA Merge node waiting for two inputs
3. CA Schedule trigger polling every second
4. DA Wait node that resumes on a webhook callbackCorrect answer

Why: The Wait node can pause the execution and resume when its resume webhook is called, so no worker is blocked during the transcription.

1. AAn OpenAI-compatible chat model with base URL https://ai-gateway.vercel.sh/v1 and an AI Gateway API keyCorrect answer
2. BStore each provider's API key and pick one in an IF node
3. CCall the gateway only from the Gmail node
4. DInstall a separate Vercel-only n8n node with provider keys

Why: The gateway is OpenAI-compatible, so one credential with that base URL reaches many providers by model name, with no provider keys in n8n.

1. AMerge
2. BText Classifier
3. CSummarisation node
4. DInformation ExtractorCorrect answer

Why: The Information Extractor, backed by an OpenAI-compatible chat model, returns structured JSON with the summary, decisions and action items.

1. AThe current timestamp
2. BA random UUID per execution
3. CThe recording ID plus the item indexCorrect answer
4. DThe task title text

Why: Step 7 uses a deterministic key built from the recording ID plus the item index, and stores the returned task IDs.

1. AThe owner is added to the invite list
2. BThe model is called repeatedly until it agrees
3. CThe IF node routes it to host reviewCorrect answer
4. DThe task is created and assigned to the host silently

Why: Step 5 checks every owner against invitee emails, and anything that fails goes to review.

1. ANo worker is blocked during long transcriptionsCorrect answer
2. BIt removes the need for speaker labels
3. CIt encrypts the audio file
4. DIt makes transcription more accurate

Why: Step 2 uses the Wait node so the execution pauses and resumes on the callback, instead of a worker sitting idle.

1. AThe model regenerates the draft and approves it
2. BThe execution ends after a timeout and sends a reminderCorrect answer
3. CTasks are auto-created from the draft
4. DEvery invitee gets the draft email

Why: Step 6 says the execution resumes on approval or ends after a timeout with a reminder. Nothing is auto-approved.

1. AThe host review form
2. BQueue mode
3. CThe Error Trigger workflow
4. DPer-node retry-on-failCorrect answer

Why: Step 9 uses per-node retry-on-fail for transient API errors. The Error Trigger workflow alerts only when the run still fails.

1. AAn atomic INSERT with a unique key on recording_id, such as ON CONFLICT DO NOTHINGCorrect answer
2. BKeep a list of processed IDs in Code node memory
3. CWait one minute and then check Gmail
4. DRead the row, then insert if it is missing

Why: A database-enforced unique insert is atomic across workers. Read-then-insert can race, and in-memory state isn't shared.

1. AThe model's system prompt alone
2. BRecipients are built only from the calendar invite list, never from model outputCorrect answer
3. CGmail's spam filter
4. DThe Wait node's timeout

Why: Step 8 emails only the invite list, so the address is excluded by deterministic code whatever the transcript says.

1. AEvery write is idempotent, using the ledger and deterministic task keysCorrect answer
2. BThe model always returns identical output
3. CRetries are turned off
4. Dn8n deletes partial results automatically

Why: Step 9 relies on idempotent writes, so reruns update or skip existing records instead of duplicating them.

1. AExecute Workflow with a Merge node
2. BLoop Over Items
3. CSet/Edit Fields
4. DError workflow with an Error TriggerCorrect answer

Why: A workflow can name an error workflow that starts with the Error Trigger node and receives details of the failed execution.

1. Aclaude-sonnet-4.5@anthropic
2. Banthropic:sonnet
3. Canthropic/claude-sonnet-4.5Correct answer
4. Dmodels/anthropic/claude

Why: Gateway model names take the provider/model form, such as "anthropic/claude-sonnet-4.5" or "openai/gpt-5".

1. AMerge
2. BSet/Edit Fields
3. CLoop Over ItemsCorrect answer
4. DSwitch

Why: Step 7 uses Loop Over Items to create each task in the project tool.

1. ABy turning on Gmail batching
2. BBy running more Wait nodes
3. CBy splitting the workflow into more Code nodes
4. DQueue mode with Redis and workersCorrect answer

Why: n8n queue mode uses Redis to distribute executions to worker processes.

1. AThe Gmail OAuth token
2. BA single AI Gateway API keyCorrect answer
3. COne API key for each model provider
4. DNo credential at all

Why: n8n holds one AI Gateway key that reaches many providers, so no provider keys live in n8n.

1. AInside each execution log
2. BEncrypted, and referenced by nodesCorrect answer
3. CAs plain text inside workflow JSON
4. DOnly in environment variables of the browser

Why: n8n stores credentials encrypted and nodes reference them instead of embedding secrets.

1. AIt lowers transcription cost
2. BIt grounds the item, so invented items can be detected and reviewedCorrect answer
3. CIt sets the due date
4. DIt is required by Gmail

Why: Step 5 checks for a supporting quote, and an item without real evidence in the transcript is routed to review.

1. AThe AI Gateway API key
2. BCompleted status with the task IDs and the model usedCorrect answer
3. COnly a completed flag
4. DThe full audio file

Why: Step 8 marks the ledger row completed with the task IDs and the model used.

1. AOnly Bash
2. BJavaScript or PythonCorrect answer
3. COnly SQL
4. DJava or C#

Why: The Code node supports JavaScript or Python.

1. ATo keep model inputs within context limits and improve extraction qualityCorrect answer
2. BTo make deterministic keys random
3. CGmail limits attachment size
4. DSpeaker labels require it

Why: Chunking keeps each model call within limits and reduces missed details in very long inputs. The results are merged afterwards.

1. AA Slack alert to the owner with the execution linkCorrect answer
2. BAn email to all attendees
3. CA new task in the project tool
4. DA request to re-transcribe the audio

Why: Step 9 says the Error Trigger workflow alerts the owner on Slack with the execution link.

1. AProviders sign the exact bytes, and re-serialised JSON may not matchCorrect answer
2. BThe raw body has the invite list
3. CThe raw body is smaller
4. Dn8n cannot parse JSON

Why: An HMAC is computed over the exact payload, so any change in formatting breaks the comparison.

1. AIt makes the recording ID deterministic
2. BIt gives time-limited access without making the recording publicCorrect answer
3. CSigned URLs transcribe faster
4. DIt is needed to get speaker labels

Why: A signed URL limits who can fetch the audio and for how long, which protects sensitive recordings.

1. ARemove retry-on-fail from every node
2. BCheck an email-sent flag in the ledger before sending, and set it right afterCorrect answer
3. CAlways send again, because emails are idempotent
4. DRely on Gmail to block repeats

Why: Email can't be un-sent, so a ledger flag checked before and written immediately after the send guards against repeats.

1. AThe audio file length
2. BThe meeting date and the host's timezoneCorrect answer
3. CThe model's confidence score
4. DThe number of invitees

Why: Relative dates can only be resolved against when the meeting happened and in which timezone.

1. AThey help attribute who said what, which supports owner assignmentCorrect answer
2. BThey replace the calendar invite list
3. CThey reduce transcription cost
4. DThey act as the deterministic task key

Why: Speaker separation helps link commitments to people. Identity is still checked against the invite list.

1. AInformation Extractor
2. BError Trigger
3. CSwitchCorrect answer
4. DWait

Why: A Switch node routes items down different branches based on a value, such as the team's chosen tool.

1. AMerge
2. BExecute WorkflowCorrect answer
3. CSet/Edit Fields
4. DSchedule Trigger

Why: The Execute Workflow node calls another workflow as a sub-workflow.

1. ACreate a placeholder task for the host
2. BRaise an error and page the owner
3. CRetry the model until it finds something
4. DAccept the empty list, send the summary, and mark completedCorrect answer

Why: An empty list is a valid outcome. Forcing items encourages invented tasks, and paging on it creates alert noise.

1. AThe Text Classifier
2. BAn OpenAI-compatible chat model sub-nodeCorrect answer
3. CThe vector store node
4. DThe embeddings node

Why: The Information Extractor is backed by an OpenAI-compatible chat model node pointed at the gateway base URL.