Agents will sometimes choose not to respond based on instructions you configure. This is generally not an approach we recommend configuring towards. The recommended approach is equipping your agent with a that triggers on a specific condition being met and takes a action and can appropriately alert the correct team member through other actions you configure on it. However sometimes, you might configure instructions that lead the agent to believe it is not supposed to respond in a certain situation. This capability was not even present on older AI models, but newer models (gpt 5.4 +, grok 4.5) can do this (and the newest ones, gpt 5.6 series, are more likely to when instructions lead that way).

To account for this, we've given agents the ability to explain why they chose not to respond. This reasoning will show up in the and allow you to adapt your agent's instructions if this is not desired behavior. (You can manually edit your agent's instructions, or copy the agent's reasoning to Ava in the Agent Editor interface and have Ava help you edit it, or simply tell Atlas to check out the contact, and Atlas can guide you through it automatically).

To see logs go to > . A message that was processed, but the agent chose not to respond will show up like this:

There are a few situations where this behavior be beneficial. An example of an intentional use: on a journey scoped agent that takes over at the stage, you could insert a rule like "if the user's message is simply acknowledging an appointment confirmation or reminder, do not respond".

, This is because no other downstream actions will take place and you will not be alerted and the conversation will likely resume later via a follow-up. The better approach for these agents is using a conditional tool to wrap things up appropriately in specific conversation ending situations.

Whatever you choose, your logs will now include the reason the agent didn't respond if it didn't.

All OpenAI models below GPT 5.4 are now deprecated in brayv. If you are pinned to an older model in one or more of your agents, please update to a newer model of your choice, or switch to as the and as the .

This will not break your agents. They will automatically route to GPT 5.6 Terra if they are on a deprecated OpenAI model until you make another explicit choice.

We've cleaned up how calendar webhooks fire, so you only get the events you've subscribed to — and two new event types are now available.

New events: and . When an appointment's status changes to completed or no-show, we now send a dedicated event instead of a generic update. Both are off by default — enable them in → → .

appointment.updated is now precise. It only fires when an appointment's time or assigned user changes, matching what the settings UI has always said. Status changes no longer arrive disguised as updates.

Your event checkboxes are now fully respected. Previously, some webhook deliveries ignored the event selections on the calendar. Now every event honors your subscription settings.

Events you can receive

— always sent when the webhook is enabled

— time or assigned user changes (on by default)

— on by default

— new, off by default

— new, off by default

: if your integration relied on receiving completed or no-show status changes as appointment.updated events, enable the new Completed / No-show events on your calendar to keep receiving them — they now arrive under their own event names.

Your existing settings are unchanged; the new events are opt-in.

— you'll find it in the left-hand menu (desktop).

Atlas is an AI assistant that understands the key configurations of your brayv.ai account and how they work together: your lead sources, journeys, agents, calendars, booking routing, assignment routing, knowledge base and how all of it works together. You talk to it in plain English. It does the technical work.

"If a customer wants a phone call instead of an on-site visit, book that instead." A change like that touches half a dozen settings that all have to agree with each other. Atlas builds every piece as one plan: what it's changing, why, and exactly what the new configuration looks like — side by side with what's there today. You review, Atlas double-checks the whole plan against your live setup for conflicts, and nothing is saved until you click Apply. Every applied plan is kept permanently, so you always have a record of what changed and why.

Flip Atlas into mode and it becomes a detective over your account's real history: full conversations, every decision your agents made, call transcripts, booking traces. "Why did this lead book with the wrong team member?" "Why didn't the AI reply here?" You get an answer backed by evidence — and if the answer turns out to be a settings fix, Atlas can build it on the spot.

"Walk me through how my account is set up" gets you a plain-English tour: where your leads come from, what happens when they arrive, and how they get to booked.

If your AI ever answered "I'm not sure" to a question you is in your knowledge base, Atlas can now run the exact same search your agents run, show you why the answer wasn't found, reword the entry so it retrieves — and prove the fix worked.

Ava isn't going anywhere — it's still your go-to for quick questions and fast edits inside the agent editors. For the full breakdown of who does what, see the "Meet Atlas & Ava" article in Help > Quick Start.

We've overhauled how queued outbound AI calls are scheduled and placed from your journeys.

. The "only call if the contact doesn't respond to text" delay used to max out at 15 minutes. You can now set it anywhere from 2 minutes to 2 days, with a new minutes/hours/days picker in the journey builder. Give your leads a full day to reply by text before the AI picks up the phone.

. Previously, if a call came due outside your allowed calling hours (say, a lead entered your journey at 3 AM), it was skipped entirely. Now the call simply waits and is placed when your calling window next opens — in the contact's own timezone if that's how you've configured the stage.

. Right before a queued call is placed — including calls that waited overnight for your calling window — we re-verify that it still makes sense:

If the contact replied by text after the call was queued, the call is cancelled.

If the opportunity was closed or already advanced to the next goal stage in your journey (for example, they booked on their own), the call is skipped.

Do Not Call and Voice AI preferences on the contact are respected as always.

Better visibility on the contact . When a call is cancelled because the contact texted back, that now shows up on the contact's activity history — just like skips from Do Not Call and Voice AI settings do. You'll always be able to see why the AI didn't call.

. We also shipped under-the-hood improvements to how queued calls are dispatched, so calls waiting on your account's concurrency limit are picked up promptly as soon as a line frees up.

: every contact now gets a CONTACT UPDATED entry on its activity history showing where a change came from, what changed, and what was ignored. Showing what fields were changed, and any changes that were skipped (and if so, why) — this covers changes team members make directly on the contact or changes that happen when a contact comes back into the system via a lead source (api, webhooks, calendar widgets, facebook forms, forms, etc). Changes AI agents make via field extractor tools are still recorded on the Text AI and Voice AI logs.

: when outbound voice ai calls are skipped (contact has outbound voice ai disabled), CALL SKIPPED entry gets logged in the activity history.

: call records (both for standard calls and voice ai) get their own activity types CALL RECEIVED, CALL MADE, CALL MISSED instead of being lumped into the generic MESSAGE type. (this change is go-forward, old activity history records remain as is, they are still distinguishable by their content, but the new type makes it easier to distinguish at-a-glance going forward).

You can view a contact's activity history by going to their contact detail page.

Every team member has a linked contact record — it's what internal SMS, escalation alerts, and your message history with them run through (that part is not new).

, we know that sometimes users want to test by submitting a real form, chatting with a text agent, booking an appointment, tracking a whole journey progression, or actually calling your voice agent. And while doing that, people type things like "Joe Test" and "asdf@test.com". Until now that would rename the user's linked contact and quietly break the notifications pointing at it.

Five fields are now protected on a team member's linked contact:

Lead sources (forms, chat and calendar widgets, webhooks, Facebook lead forms, the public API), AI field extractors on both text and voice agents, and CSV import all skip them. Everything else saves exactly as it would for a real lead — address, custom fields, journey enrollment, appointments, conversations. Your test still runs end to end.

These fields come from the team member's user profile. If they need to actually be changed, you can change them in (or for your own) and the update flows down to their linked contact. (a user's email can only be changed by contacting support@brayv.ai).

every contact now gets a entry on its activity history showing where a change came from, what changed, and what was ignored. After a test, open the contact and you'll see exactly what was submitted — including the dummy name that was correctly refused.

Want to reduce the chance of your calls showing up as "Spam Likely"? You can now register your business for carrier verification right from Settings → Phone.

One request covers all your numbers — including AI voice agent lines — and any numbers you add later are covered automatically. Just fill out the short form with your legal business details (most of it is pre-filled from your account), and carrier review typically takes a few business days. You can track approval status right on the page, and if a request is rejected you can fix the details and resubmit.

Newly released frontier models from and are now available in .

If you pin your provider to OpenAI, you can now select

If you pin your provider to Grok/xAI, you can now select

All four of these new options performed very well in robust testing with various agents. To know what works best for you, we always recommend testing your agent.

If you're not sure which model to select, we always recommend selecting as the provider and as the model, which lets the system pick a model for you dynamically that the system determines will handle your current agent configuration well. will only ever run your agent with a "frontier" model (ie the most generally capable ones).

Ava got some significant intelligence improvements today — especially related to complex routing rules for booking — Ava can intuit and one-shot your super complex rules more consistently now. In addition to that, all Ava modes now reason more thoroughly before responding.

When generating booking rules and assignment rules, so you can visually see the 'map' of your rules. This should help spot check whether your rules are actually what you want instead of reading through a hundred lines of rules explained in text.

To check it out simply go into any agent that has booking or lead assignment in the Booking/Goal tab, and click on

You'll then see an interface like this which you can drag/zoom as needed to get the whole picture!

We recorded a video course which covers things like what you need to know on a day to day basis with how leads flow through the system, and overviews of major features. Check it out soon and work through it at your own pace!

It is at the top of the help home page

It can also be accessed in the section of the menu.

You can get to by clicking on the icon button in the main left hand menu in when you are logged into hub.brayv.ai