A2A Coordination: Book meetings with Hermes agents on Blocks.ai

NOTE: This blog is a crosspost from https://blocks.ai/blog/hermes-a2a-meeting-coordination

The Hermes + Blocks.ai guide gets a Hermes assistant onto the Blocks Network. This companion tutorial starts where that guide ends and adds the calendar workflow from the video embedded with this article: two owners, two private agents, mutual availability, human approval, and one shared event.

Start with the main guide: For each owner, follow https://blocks.ai/docs/hermes through the private registration and Blocks.ai test. Keep the agent Private + Free and leave its local runner online. Do not publish it for this tutorial.

Follow the guide: Use Hermes to create a Blocks.ai agent

What the main guide already handles

• Starting Hermes and choosing a model provider.
• Connecting Telegram so each owner can chat with their own Hermes assistant.
• Loading the Blocks.ai Skill and scaffolding a validated Blocks.ai project.
• Authenticating the Blocks.ai CLI, registering the agent privately, and starting blocks run.
• Testing the generated agent through the Blocks Network.

Hermes and the Blocks.ai CLI will evolve, so we won't waste your time or ours repeating them here — the guide will be maintained as both grow instead.

Hermes–Blocks.ai integration skill: blocksnetwork/hermes-blocks on GitHub

What you'll do in this tutorial

• Authorize each owner's Google Calendar inside their own Hermes data directory.
• Turn each generated private Blocks.ai project into a calendar agent.
• Grant the two agents mutual private access and exchange only non-secret contact and routing details.
• Ask for a meeting, approve it, and verify one shared Google Calendar event.

Keep ownership separate: Each person keeps a separate Hermes data directory, Google authorization, Blocks.ai account and API key, Telegram bot, and calendar-agent project. Never copy one owner's Hermes data directory, or the project's environment file that holds the Blocks.ai API key and calendar tokens, to the other owner.

Before you begin: Set up for success

You need two owners. Each owner needs:

• A Blocks.ai account, the email address used for that account, a Blocks.ai API key, a Docker host, a supported model-provider API key, and a Telegram bot for chatting with Hermes, as required by the main Hermes guide.
• A Google account with Google Calendar. Use that Google account's address as the owner's meeting email so invitations appear on the calendar connected in Step 2.
• A unique Blocks.ai agent name and an IANA time zone, such as Europe/Warsaw or America/Los_Angeles.

Step 1: Finish the main guide for the first owner

Follow the Hermes guide using the first owner's Blocks.ai account, model-provider API key, Telegram bot, and Hermes data directory. Its running example asks Hermes to become an SEO expert. For this tutorial, replace that example: tell Hermes to become a personal assistant that can manage the owner's Google Calendar events. Use a unique Blocks.ai agent name such as john_calendar_48291. Step 3 will add the private agent-to-agent meeting workflow.

Send this to Hermes:

Become my personal assistant. Help me manage my Google Calendar, find free time, propose meetings, and create or change calendar events only after I confirm. We will connect this personal assistant to the Blocks Network as a private agent.

Stop after the private Blocks.ai test succeeds and keep its local runner online. You do not need to publish the agent. Hermes will locate this generated project again in Step 3.

Ready state: Hermes answers in Telegram, blocks check passes, the agent is Private + Free, blocks run is online, and the guide's trigger test returns a result (the guide calls this an artifact).

Step 2: Ask Hermes to connect the first owner's Google Calendar

Hermes includes a Google Workspace skill. Do not follow a fixed OAuth recipe in this post; the installed skill is the source of truth. Ask Hermes to inspect its current setup, guide you one step at a time, and verify the connection itself. A silent host-side command is a command you run on the Docker host that accepts sensitive input without echoing it or adding it to the chat transcript.

Send this to Hermes:

Connect my Google Calendar to this Hermes instance using the bundled Google Workspace skill. Inspect the installed skill and guide me one step at a time using its current flow. Ask before every external change. Keep all secrets, client files, callback URLs, authorization codes, and tokens out of chat; whenever sensitive input is required, give me a silent host-side command. Request Calendar access only. Finish by running a live, read-only Calendar check. Do not create, change, or delete any event yet.

Follow the instructions Hermes returns. If any screen or command differs from what Hermes expects, describe exactly what you see and ask it to adapt to the installed skill instead of guessing. Continue only after Hermes completes the read-only check.

Gate: Continue only after Hermes reports that a live Calendar check succeeded. Never send the Google client secret or saved token to the other owner.

Step 3: Turn the existing Blocks.ai project into a calendar agent

Don't scaffold a second Blocks.ai project. Ask Hermes to update the project created by the main guide and reuse the Google authorization you just verified. The prompt introduces a colleague registry: a small, owner-controlled project file that maps each colleague alias to a Blocks.ai agent name, meeting email, IANA time zone, and display name. The Blocks.ai account email used for private-access invitations is separate and may differ from the meeting email.

Send this to Hermes:

Locate the existing Blocks.ai project that the main guide created for my private agent. Inspect the current Hermes environment and recent setup state instead of asking me for a filesystem path. Before editing, tell me the project directory and agent name you found and ask me to confirm; if you find more than one candidate, list them and let me choose. Then update the confirmed project into my private calendar agent. Reuse the working Google Workspace authorization stored in this Hermes data directory. Keep the peer workflow limited to health, free_busy, and request_create. free_busy must return only busy intervals, never event titles, descriptions, or attendee lists. Persist pending requests on disk. Add owner-local pending, approve, and reject helpers that use the same project directory and pending-request store as the running agent; a requesting peer must never approve its own request. For request_create, resolve the invitee from requesterAgent through the colleague registry and reject unknown agents, aliases, or arbitrary attendee addresses. On owner approval, create exactly one Google Calendar event, invite the registry email, and send the decision back to requesterAgent over the Blocks Network. Add a local find-mutual-time helper that queries both agents over the Blocks Network, checks weekdays from 08:00 to 21:00 in both stored IANA time zones, and then sends request_create. Keep duration, days ahead, and working hours configurable. Store credentials only in the ignored project environment file, never print them, and scan every generated source file for hard-coded API keys, tokens, client secrets, or authorization codes. Then run typecheck, local tests, and blocks check. Do not publish the agent.

When the changes pass locally, return to the main Hermes guide at its private registration and Blocks.ai test sections. Re-register the updated private project if Hermes changed the agent card — the published description of the agent and its triggers — restart its local runner, and confirm health plus a read-only free_busy request. The linked guide remains the source of truth for the current CLI commands.

Safety check: The free_busy test may read availability, but it must not create, update, or delete an event. Continue only after Hermes confirms that its project scan found no credential outside the ignored environment file.

Step 4: Have the second owner repeat the same path

The second owner follows the same maintained Hermes guide, then repeats Steps 2–3 of this tutorial with their own Google account and authorization, Hermes data directory, Blocks.ai account and API key, Telegram bot, and unique Blocks.ai agent name. There is no need to duplicate the guide or the calendar instructions.

Same host: If both assistants run on one Docker host, use different container names and different mounted Hermes data directories. Never run both against the same Hermes data directory.

When both owners have finished Steps 2–3 — the health trigger returns status: ok and a read-only free_busy request answers — exchange only these non-secret values:

• Blocks.ai calendar-agent name
• Blocks.ai account email used to receive and accept a private-access invitation
• Google meeting email connected in Step 2
• IANA time zone, such as Europe/Warsaw or America/Los_Angeles
• Display name or colleague's alias

Step 5: Grant mutual private access

Private agents cannot call one another until access is granted. Follow the Blocks.ai private-agent access guide twice:

• The first owner invites the email address of the second owner's Blocks.ai account.
• The second owner invites the first owner's Blocks.ai account email.

Each invitee must accept while signed in with the invited address.

Follow: Manage access to private agents

The private-access email identifies the Blocks.ai account that may call the agent. It is not an agent name and it does not have to match the Google meeting email used for calendar invitations.

Send this to Hermes:

Help me invite to call my private calendar agent . Follow the current Blocks.ai private-agent access guide, tell me exactly what I must do as the owner, and wait for my confirmation. Then help me verify that the invitation was accepted and became an active grant.

Gate: Continue only when the grants list shows the other owner's Blocks.ai account email as an active grant on each agent. A sent or pending invitation is not enough.

Step 6: Add colleague details and test the route

Send this to Hermes:

Add Mark as a colleague for my calendar agent. His Blocks.ai agent name is mark_calendar_73104, his Google meeting email is mark@example.com, his time zone is America/Los_Angeles, and his display name is Mark. Store only these values in the owner-controlled colleague registry. Configure the mutual-time helper to check weekdays from 08:00 to 21:00 in both owners' local time zones, as in the demo, unless I choose different hours. Use the registry entry when sending a request and reject unknown aliases or agent names. Then run a private free_busy test through the Blocks Network. Do not create an event.

The second owner adds the first owner in the same way and runs the reverse free_busy test. This catches a wrong agent name, missing access grant, bad time zone, or broken Calendar authorization before a real request.

Gate: Continue only after the free_busy test succeeds in both directions.

Step 7: Choose how the receiving owner approves

In the demo, we use the same Telegram bot the receiving owner already uses to talk to Hermes. The calendar agent sends a reply keyboard whose button labels are approval commands. Tapping a button sends that label back as a normal chat message, so the Hermes gateway handles it without a second bot, webhook, or callback bridge.

Send this to Hermes:

Show my pending meeting requests. For each one, show the title, local start time, duration, requester, and request ID. Do not approve anything yet.

If you use another chat channel, keep the manual pending-request flow and send the approval or rejection message yourself.

Send this to Hermes:

Add the demo's approval flow to the receiving calendar agent using my existing Hermes Telegram bot. Send a Telegram reply keyboard, not inline callback buttons. Label the buttons 'approve ' and 'reject ' so a tap returns a normal message to Hermes. Reuse the bot settings already stored in this Hermes data directory without printing or copying the token into chat. Only the Hermes gateway may poll updates. When an approval message arrives, list the pending requests from the same project directory and pending-request store as the running agent, match the live request ID, and invoke the owner-local approve or reject helper. Do not hard-code a request ID. Test the keyboard and message routing without creating an event.

Verified demo path: Use the existing Hermes bot plus reply-keyboard commands. Do not create a second Telegram bot or run a callback bridge.

Step 8: Book the meeting

In the first owner's chat with Hermes, send:

Send this to Hermes:

Find a time this week that works for both Mark and me, and set up a quick 15-minute sync. Ask him to confirm.

The assistants now complete this loop:

• The first owner's Hermes runs the local mutual-time helper.
• The helper asks both the local and remote calendar agents for free/busy information over the Blocks Network.
• It finds a weekday slot between 08:00 and 21:00 in both stored IANA time zones.
• It sends request_create to the second calendar agent with the requesting agent's name.
• The second agent persists the request and sends reply-keyboard approval buttons to its owner in Telegram.
• A button tap returns an approve or reject message to the second owner's Hermes, which lists pending requests and uses the live request ID.
• On approval, the second calendar agent creates one event, invites the first owner's registry email, and sends the decision back to the first agent over the Blocks Network.

If the buttons are unavailable, send Show my pending meeting requests. Review the title, time, and attendee, then send approve or reject .

Demo time zones: The recording uses Europe/Warsaw and America/Los_Angeles with a shared 08:00–21:00 weekday window. Store IANA time-zone names and let the calendar APIs handle daylight-saving changes.

Step 9: Verify the shared calendar event

• Open the approving owner's Google Calendar.
• Find the 15-minute event at the agreed time.
• Confirm the other owner's email is on the guest list.
• Confirm both people see the same shared event, not two unrelated copies.

Telegram carries only the conversation between each owner and their own assistant. The free/busy request, meeting proposal, and decision result travel between the assistants over the Blocks Network.

What moved between the assistants

• Calendar credentials stayed local. Neither owner sent an OAuth secret or saved token to the other agent.
• The Blocks Network carried scoped requests. The agents exchanged availability, a proposal, and the final decision over their private route.
• Approval remains human. The assistants propose a slot, but the receiving owner is looped in at the exact moment they're needed to decide whether to book it.
• The event is shared once. Only the approving agent creates it and invites the requester.

When something goes wrong, ask Hermes

Don't debug by copying commands from an older tutorial. Tell Hermes the exact symptom and ask it to inspect the current container, installed skills, generated project, runner state, and relevant logs.

Send this to Hermes:

Troubleshoot the failure I just encountered at . The exact symptom is: . Inspect the current Hermes setup, installed skills, calendar authorization status, generated Blocks.ai project, accepted private grants, runner state, and relevant logs. If approval says 'Request not found,' first compare the helper's project path and pending-request store with the running agent, list the live pending requests, and use the ID returned there; never use a hard-coded request ID. Scan source files for hard-coded credentials without printing any secret. Explain the root cause in plain language, then give me one safe next action at a time. Do not ask me to paste secrets into chat, do not delete or rotate credentials, and do not create or change any calendar event while diagnosing.

If the problem belongs to the base Hermes-to-Blocks.ai setup, ask Hermes to take you back to the matching section of the maintained guide. For calendar, access, approval-button, time-zone, or duplicate-event problems, have Hermes run a read-only diagnostic first and explain what it found before making a change.

And that's it. Let me know what you think — I'm Dawid Urbas, Developer Relations Engineer at PubNub working on Blocks.ai. Tag me on Twitter @getbold_ if you have questions, concerns, or improvements.