1. A demo request arrives from the website form in HubSpot. HubSpot gives the fields to the agent. No person fills in a form.
2. The agent picks the date, finds the airport, sets the time limits, searches flights, cars and rooms, and applies the travel policy. This page does the planning now. I ran the searches once with Claude Code and recorded the results.
3. The agent makes one request with one line for each booking, as on this page. A person approves one line, or all lines with one press.
4. The agent books each approved line and posts the confirmations. See “How the agent books”.
5. The itinerary, the deadlines, the run sheet and the guest messages go to Slack, the calendar, Notion and Intercom.

Steps 1, 4 and 5 need access to Brumby systems. Step 2 needs a flight search service in place of the recorded searches.

It is one agent with a small number of connections. A person signs in to each connection once.

• Inbox: the agent reads the demo requests and the replies. It writes each answer as a draft.
• Slack: the agent posts the request in the demo channel. A person accepts and approves there.
• Calendar: the agent reads the free days of the crew and the pilot, and it makes the holds. In my test the agent read my own Google Calendar for the days around both dates, then made 9 holds for this plan. No hold has a guest.
• Notion: the demo record and the travel policy.
• Intercom: the contact and the follow-up messages.
• Flight search: live options in place of the recorded searches.

The agent reads one shared inbox and one channel. It does not read personal mail or direct messages. In my test the inbox and the calendar were live, on my own accounts. I started the agent by hand. In the live tool the form starts it. The agent found the test message in the inbox, read it, and wrote the reply as a draft in the same thread. It sent nothing. The page itself does not connect to an inbox or a calendar. The agent instructions are in the repository: skill/demo-intake and skill/demo-trip-agent. I ran the intake steps on the test message, and the record on this page is the result.

The Brumby demo form sends each request to HubSpot as a set of fields: the name, the email, the phone if the grazier gives it, where the stock is, the herd size, the main reason, how often the mob moves and the timing.

In the company version, a HubSpot workflow calls the agent when a form arrives. The agent takes the fields, so it does not interpret an email. The repository has the handler: intake/hubspot_to_record.py. I tested it with two sample submissions that use the field names of the form.

The workflow step is “Send a webhook”. HubSpot lists it for Data Hub Professional and Enterprise. Source I do not know which plan Brumby has. With a different plan, the agent reads the new submissions from HubSpot at a set interval. The result is the same request.

The form does not give the property address, the date or the guest count. That context is in other places: the reply from the grazier, the crew calendars and the demo channel. For this reason the agent still needs the inbox, the calendar and Slack.

To run it for a company

• Company accounts: a shared mailbox, a Slack app in one channel, a shared demo calendar and a HubSpot key. No personal login.
• A small service that is always on. A form, a Slack button or a reply starts it.
• One record for each demo, in HubSpot or Notion.
• Approvals as buttons in Slack, a spend limit and a log of each action.
• Three stages: the agent only posts its plan for 2 weeks, then it prepares and a person approves, then the low-risk steps run with no press.

I have not built this part. The prototype stops at the booking page. This is the design.

• Flights: a booking service with an interface for software. Duffel lists search and booking for Qantas, Jetstar and Virgin Australia. For Virgin Australia it lists paid bags, changes and refunds as coming soon. The agent makes the order and pays from the balance of the company account. Source The agent does not hold a card number. I have not tested Duffel on these routes.
• Rooms: Duffel also has an accommodation service. Access is on request. Source
• Car: I have not checked a booking service for the car. For now the agent opens the booking page with the trip filled in, and a person pays. A second option is a virtual card for one payment with an amount limit. Source
• Freight: I do not know how Brumby moves the kit. The agent sets the dates and writes the freight details. The details go to the carrier account or the freight contact that Brumby uses.

Three controls apply to each booking: a spend limit, a price check at the time of booking, and a log. If the price is above the approved price, the agent stops and asks again.

The first four rows are in this prototype. The last four use the same record and the same connections.

The rules are in one object in the code. Each rule is a guess until Brumby sets it.

Cut

Live prices on the page, payment, and United States ranch demos. The role has domestic travel, so I kept to three Australian regions.

Guessed

The planner rules, the demo format, the freight lead time and the freight method. I have not been to a Brumby demo day. For this reason the schedule is a template that you can edit.

Next

Connect a flight search service so the shortlist shows on this page for each request. That needs an account with a flight data provider and a small server. Then send the shortlist to Slack for approval.

Built

With Claude Code, in one evening. Each fact has a link to its source.

Weather and town search by Open-Meteo.com. Sunrise is calculated from the date and the location.