Why I built a second game tool

A lot of you know vbgnt, the game platform I have been working on. vbgnt is invite-only right now because every single game runs its own coding agent inside a dedicated cloud microVM.

arcadegnt started out on my desk as "vbgnt Lite." The core idea was simple: what if arcadegnt never runs a model at all?

When you connect arcadegnt, your existing assistant (Claude, ChatGPT, Cursor, Codex, OpenCode, or whatever MCP client you prefer) does the actual thinking. You use the subscription you already pay for. Because arcadegnt only handles the file system, the Godot engine builds, headless browser testing, and static web hosting, our operating costs stay low. That is why the core product can be free.

Under the hood, it shares vbgnt's custom web export settings, our multitouch fixes for mobile Godot games, and our online leaderboard system. If you ever want to move a project from arcadegnt over to vbgnt, it ports right over cleanly.

How the build and test loop works

When you tell your assistant to create a game, it writes GDScript files directly into an arcadegnt project directory. You do not touch an export menu or install Godot on your machine.

The moment the files are ready, the assistant runs a build command. arcadegnt imports the project, parses every single scene and script, and runs the game headlessly for three seconds to verify that it does not crash on frame one. If there is a typo or a broken signal, the compiler returns the exact file, line number, and error message directly to the assistant. The assistant patches the script and triggers another build.

Once the build passes, arcadegnt publishes a playable version immediately to the game's own play address, <slug>.arcadegnt-play.com.

Then the assistant can run a command called check_game. arcadegnt spins up headless desktop and mobile instances of Chrome, loads the live link, simulates keystrokes or screen taps, and captures up to eight screenshots. It also checks for solid-color frames, which catches the common bug where a project compiles fine but sits on a blank black screen. The assistant inspects those screenshots, fixes whatever looks wrong, and rebuilds.

That exact loop created Dodge Drop, a small neon meteor dodger you can play on your phone right now.

Handling game assets

You have a few ways to handle visual and audio assets.

If you have your own files, you can drop sprite sheets, audio tracks, custom fonts, or 3D GLB files straight through an upload link, or paste a link to a Kenney or itch.io pack. arcadegnt inspects every file on upload. It measures image dimensions, checks audio playback lengths, and renders 3D models from four camera angles so your assistant understands the proportions of what it is working with. If you use other MCP servers like Meshy for 3D meshes or PixelLab for sprites, you can chain them into the same conversation.

If you give it zero files, the assistant writes procedural assets. It can generate SVG sprites, write custom screen shaders, synthesize sounds using code, and assemble 3D objects from primitive geometry.

The public Arcade

Every published game comes with touch controls, gamepad support, play analytics, and a top-100 high score leaderboard that flags suspicious inputs. You can download the complete Godot project zip file whenever you want. You own everything you make.

When your game feels solid, you can submit it to the Arcade, our public gallery. Every single Arcade submission is played and approved by a real human being before it appears in public listings.

Once approved, arcadegnt creates an immutable, frozen copy of that specific build at its public link. That ensures broken updates or unvetted scripts never run on the primary domain. Players can browse the gallery, bookmark favorites, or use a random mode that flips through full-screen games with a single tap.

What it does not do yet

I want to be clear about the current technical limits so nobody wastes an afternoon hitting a wall.

First, there is no online multiplayer networking. You can build single-player games, turn-based games, or shared-screen local multiplayer, but not real-time peer-to-peer or client-server lobbies.

Second, the 3D pipeline relies on Godot's web Compatibility renderer. It supports standard meshes, materials, lighting, dynamic shadows, fog, and particle systems. It does not support volumetric fog or real-time global illumination.

Third, arcadegnt does not generate AI art internally. It only consumes the assets you supply or the code your assistant writes.

Finally, total project export size caps out at 150 MB per game.

Setting it up

The free tier includes up to two games with full build, test, and hosting tools. No credit card required.

If you need more headroom, arcadegnt Gold is $10 a month (or $108 a year). That bumps your limit to ten games, adds a gold coin star to your games in the Arcade, prioritizes your submissions in the human review queue, gives your games more rotation spots in random mode, and sends a weekly email with your Arcade games' plays and ratings. Gold accounts still go through the same review checks as everyone else.

Setup takes about sixty seconds:

1. Copy the server link: https://arcadegnt.com/mcp
2. Add it as an MCP server inside your chat client settings.
3. Confirm your email address on the initial prompt.

Once it is added, open a new chat and ask your assistant to build a tiny prototype. You can read the documentation and explore live community projects directly at arcadegnt.com.

I ran it on four of my own games the day it worked. Everything below is straight out of those campaigns.

What a campaign is

You tell it four things. What the campaign is about: a launch, an update (you say what changed, and the agent checks each change is really in the project before announcing it), or anything in your own words, like a Halloween event. How long it runs, from one day to sixty. Where it goes: TikTok, Instagram Reels, YouTube Shorts, a landscape YouTube video, Reddit and X, each its own tick box. And two optional extras, a voice-over and an AI-generated opening shot, both off unless you ask.

Then it runs in the background, like a build, and builds on the game's marketing kit when there is one. My four took between 34 and 68 minutes. What comes back is a calendar: every post written out with copy buttons, the video it uses, a tick box for when you've posted it, and a button that drops the whole schedule into your calendar as reminders.

The videos are the game

The shorts are cut from real gameplay. If the kit made a trailer, the agent cuts from that footage. If not, it records the game itself, using Godot's movie-maker mode on a scratch copy of the project, 30 frames a second with the game's real sound, while a script plays it. It records a library of shots once and cuts every short from it, because rendering is the slow part and recutting is cheap. And one file goes everywhere: the same vertical short is the TikTok, the Reel, the Short, and the video on X and Reddit. Only the caption changes. I made that a rule after realising the obvious alternative, a render per platform, turns a forty-minute job into a three-hour one.

A short is built for a phone, not a cinema. The hook is on screen in the first second, a few fast beats follow with big burned-in captions because most people watch muted, the best moment comes last, and the final frame cuts back to the first so it loops.

The AI opener, and saying so

The opening shot was the fun part. Each campaign ran on one joke: the dungeon's staff commuting to work, a cat lady who wants to know how many cats one person can carry, a future immortal who still has a commute, a witch with a takeaway coffee on her way to her potion-piling shift. With the AI hook ticked, the agent opens a short on a few seconds of generated live action built around the game's own characters (it uses a MiniMax video model on fal), then cuts hard to the real game.

There are rules around it, because this is exactly the kind of thing that goes wrong quietly. The opener is capped at five seconds and never more than about a third of the short. It can't look like gameplay: no interface, no mechanics the game doesn't have. And it's disclosed. Every post that uses one carries a note telling me to switch on the platform's AI-content label when I post it, and the plan marks the video. The captions went further than I asked. The Dungeon Spin TikTok caption reads: "Intro is AI, the rest is the real game."

The voice-over is optional too. It uses Gemini's text-to-speech when there's a Gemini key and a fal voice when there isn't, reads as an excited creator talking about their own game rather than a movie-trailer announcer, and puts the hook out loud in the first second.

Reddit, done the way Reddit wants

This is the part I was most nervous about, because the easy version of it is spam. The agent searches for subreddits that fit the game, then reads each one's rules, posting requirements and activity through Reddit's API. That needed a proper API key: Reddit now refuses anonymous requests even from my own laptop. Subreddits that ban self-promotion or AI-made games get dropped, and listed, so I don't try them. For Dungeon Spin it kept eleven and posts to seven, one a day, and the notes are what make it useful: r/playmygame wants the game free to play right now, r/aigamedev wants the post to be about how the game was made.

The posts are maker posts. "I made Dungeon Spin, a free browser bubble shooter where every hit spins the horde." The first comment says I'm fixing things this week and asks for "this felt unfair" notes. No pretending to be a player who found it, no vote-swap suggestions, no invented numbers, and Reddit and X are never posted automatically. I post those myself.

Changing it, and the day I scheduled ten posts at once

A campaign is a draft, not a verdict. Revise takes feedback on the whole thing, on one post, or on one video: every video and image has a "Change this" button, so "make the hook text bigger on this one" goes to that file, and the agent keeps the file name so every post using it picks up the new version.

For the TikTok, Instagram and YouTube posts, the studio can also schedule them for me: I connect a post scheduler once in Settings, tick the posts I approve, pick which of my accounts each goes to, and the agent books them at their planned times. Nothing goes out without that approval.

Then I started all four campaigns on the same day and found ten posts landing on it. So now posts move too, at any time: one post, everything on a crowded day, or the whole campaign, and anything already booked moves in the scheduler as well. That feature exists because of my own schedule.

Your agent can run it

vbgnt is also an MCP server, and Promote is in it now, so Claude or any agent you connect can plan a campaign, revise it and move posts around. Scheduling to real accounts is the one place I made it stricter than everything else: the agent has to ask you which accounts to use, show you a preview of every post, time and account, and only schedule after you say yes. It publishes in your name, so you should be the one who decides where.

The full write-up, with all four campaigns and more of the videos, is on the vbgnt blog. The studio is still invite-only; you can ask for an invite here.

Claude Opus 5.5 is now in vbgnt's model picker, and the scope of what comes out jumped immediately. The first three games I built with it are much larger in scale and mechanical complexity. Each one started from a single written prompt, followed by a handful of follow-up notes after I played the early builds. The studio plays every build in a headless browser on desktop and phone before handing it back, which catches control and viewport problems before you ever test the link.

Kartropolis

I asked for a 3D superhero kart racer where characters race through cities during alien invasions and supervillain attacks. The brief asked for Mario Kart style power-ups, an ult meter filled by drifting, passing, dodging, and landing hits, a boss arena after every race, a bright animated-film look, and voiced catchphrases.

The first build came back with four original heroes: Captain Comet, Volt Vixen, Titan Tess, and Frostbyte. Each had voice lines and an ultimate ability. It also built two tracks. Downtown Invasion sends racers down city avenues while alien saucers fire lasers at the road and a mothership hovers overhead. Harbor Havoc takes place at sunset against bomber drones and a giant robot standing in the bay. Crossing the finish line drops all four racers into a boss fight against The Overmind or The Mega-Bot. It included Homing Rockets, Goo Bombs, Turbos, Force Shields, three-stage drift sparks, two-player split screen, and controls for keyboard, gamepad, and phone screens.

A couple of follow-up notes were needed. In the initial build, each wheel had its pivot set below its real center, so the karts rolled down the track like eggs. Captain Comet also had strange webbing on his face and a stiff, modeled cape stuck to his back. I asked for a new model without a cape, plus a cape simulated in code. The studio replaced it with a starry indigo cloth cape that drapes over the kart when parked, streams straight out at speed, swings into turns, and glows when he hits a boost.

Play Kartropolis.

Cat Person

The brief for this one was simple: a cat lady runs down a city street collecting stray cats that stick to her body. Once she gathers enough cats, the group forms a Katamari-style ball and keeps rolling, growing bigger and bigger.

The studio built a third-person 3D roll-'em-up with ten distinct cat models: an orange tabby, a googly-eyed black cat, a grumpy Persian with a bow, a derpy Siamese, a calico, a tiny kitten, a sphynx in a sweater, and a tuxedo cat, among others. At the start, cats cling to her arms and legs, and right on top of her head. Once you collect ten cats, they swirl into a rolling ball with the cat lady running on top. From there you roll up cars, taxis, hydrants, street lamps, trees, and eventually buildings. The whole run lasts five to eight minutes, and I will not spoil what happens after you leave the pavement.

The follow-up notes on this one were about pacing and presentation. The original title screen showed the space levels, giving away the ending before anyone took a step. I asked it to pull that back. The revised cover shows the cat lady hugging cats on a sidewalk, with the menu line reading "ROLL UP EVERY CAT IN THE CITY". I also had to fix the traffic: the cars were initially driving backwards down the street, so the agent turned them around to drive headlights-first.

Play Cat Person.

Fat Bear Week

I asked for a bear simulator set on the real map of Katmai National Park. You wake from hibernation skinny, spend the summer eating to get fat for the winter, and watch your bear expand until it looks absurd. The brief asked for realistic geography mixed with humor, AI rival bears, an end-of-season tournament ranking everyone by fatness, and multiplayer later on.

The game drops you as a thin brown bear on the real Brooks River. You spend the season catching salmon at Brooks Falls, grazing on sedges, digging for clams, harvesting berries, and bullying rival bears off the gravel bars. As you eat, your bear expands outward and the HUD updates your rank from "Skin and Bones" up to "Chonk Legend". At the end of the season, Fat Bear Week ranks every bear by final weight. The game borrows its name and format from the real Fat Bear Week run by Katmai National Park and explore.org, but it has no official affiliation with them.

Multiplayer was flagged as a later goal in the initial brief, and it was added over subsequent turns. Rooms support up to eight bears using a four-letter room code, and AI rivals fill any spots humans leave open. It includes proximity voice chat that you toggle with the V key. Nearby bears can talk to each other while fishing the falls, and nobody hears you past about 55 meters. It is still early.

Play Fat Bear Week.

Where to play them

All three games play free in a browser on desktop or phone. You can plug in a controller for Kartropolis, spend five minutes rolling up a city in Cat Person, or jump into Brooks River with a friend in Fat Bear Week.

If you want to build games like these, vbgnt is the studio that made them.

I have written here before about the studio building the game, and then about it building the store kit. This post is about the part that comes after all of that: what it actually takes to go from a deployed build to a listing a stranger can install, and how much of that the agent handled versus how much was me.

Potion Pile

You slide to aim and release to drop jewel-like ingredients into a cauldron. Matching pieces tumble together and merge, and the merges climb eight tiers, from a Berry up to the Moon Elixir. A recipe card sits at the top of the screen and rotates between Dewdrop Tonic, Moonrise Tea and Starlight Cordial, asking for more demanding ingredients the longer you last. When the ingredients it wants are in the pot, you tap Brew, the recipe bottles for points, and the pile gets a little shorter.

The part I did not expect to like as much as I do is the Stir. Every brew earns one, you can bank up to five, and spending one gives the pile a gentle swirl that jostles everything into new positions. It is the only real escape valve in the game, so the interesting decision is not where to drop, it is when to admit you are in trouble. Keep the settled ingredients under the danger line and the run continues. It plays in portrait and landscape, and it saves your best score.

Nine Heavens Ascent

This one started as a xianxia idle game and stayed one. You begin as a nameless mortal with a few breaths of Qi, tap the sanctuary to gather more, and buy into eight idle sources that keep gathering while you are gone. Nine realms sit above you, each with nine stages, and getting through one means accumulating enough Qi to break through to the next.

At realm boundaries the heavens object. A lightning tribulation starts and you tap the falling bolts to deflect them before the trial runs out, which is the only part of the game that asks for your reflexes rather than your patience. Underneath that there are five Techniques to study, pills to craft for a timed boost, and spirit beast hunts that run on their own and pay in Spirit Stones. Later you unlock Reincarnation: you start another life, keep your Stones and Techniques, and spend Dao Insight on twelve permanent nodes plus a repeatable Samsara wheel. Get all the way to the top and there is a True Immortal ending waiting, with a record of how many lives you lived and how many breaths you took to get there.

What the studio did and what I did

vbgnt wrote both games in Godot from a written brief and a long tail of follow-up prompts, and it produced the store kit for each one: phone and tablet screenshots at the sizes the stores demand, the icons, the feature graphic, listing copy with the character counts already checked against each field, and trailers. It also produced the shippable builds, a signed Android AAB on one side and an Xcode project on the other.

What was left for me was the boring and unavoidable half. The iOS side comes out as an Xcode project rather than a finished build, because the build server runs Linux and an App Store archive has to happen on a Mac, so I set the team and the bundle id, archived, and uploaded. Then the questionnaires: age rating, data collection, export compliance, a support page, a privacy policy. None of that is hard. It is just nobody else's job, and no agent I know of can sign an affidavit about your data practices for you.

What it would not do

My favorite detail from the kit run is a refusal. When the agent recorded the Nine Heavens Ascent trailer, it would not load a prepared save to reach the late game. It played normally, got as far as normal play gets in a recording session, and then wrote in its own delivery notes that the trailer is a fallback cut missing reincarnation and the ending, along with instructions for splicing that footage in later if I wanted it. The screenshots are a different story, and it treated them differently on purpose: those were captured from saves it had actually earned, which is how you end up with a True Immortal screen in the listing but not in the trailer.

That distinction is not one I asked for, and I would not have thought to draw it that carefully. It is the kind of thing I want more of from software that makes claims on my behalf.

Where to get them

Potion Pile is on the App Store and on Google Play. Nine Heavens Ascent is on the App Store and on Google Play. Both are free.

If you want to make one of your own, vbgnt is the thing that built them.

Then I forked the vbgnt studio and pointed it at apps instead of games. That fork is appgnt. The machine is the same shape: a cloud microVM per session, a coding agent, a headless browser that tests the result before a human sees it, and a publish step. What changed is what gets built. Instead of a Godot game, it builds a React app, along with everything that real software needs: offline data, accounts, a backend, native installers, store listings, and custom domains.

You can open the output right now

The fastest way to understand it is to open something. Here are five apps built in the studio, climbing from a single-user utility to multi-user operations:

• Sprout: A houseplant watering and feeding log. You can add plant photos and set evening-before reminders. Data stays on the device, with no account required.
• Chores: A shared household chore rota. It uses email sign-in, syncs across devices, and keeps a permanent record of who actually did each chore.
• Subs: A Sunday football team sheet. It tracks who is in, match details, fees, and lifts. Players manage their own replies, while only the organizer can mark payments as received.
• SiteSheet: A job sheet for maintenance crews working on a phone on site. It captures before and after photos, collects a finger-drawn customer signature, and locks jobs once signed. Everything stays on the device so it works without cellular signal.
• Ledger: A letting agency app for managing shared tenancies, rent, and photo repairs. It includes private tenant access and runs nightly rent chases with an exact email history.

There are more examples on the front page, including Water Tracker, Petster, Alarm Face, PrioriTask, and StockTake. Each one started as a description.

What's underneath

1. You describe it: You explain who uses the app, the one job it does, the data it holds, the target devices, and what should happen when there is no signal. A sentence works, but a paragraph is better.
2. The agent builds it: A cloud microVM boots with the toolchain, kept warm across the conversation. It creates a real React, TypeScript, and Vite project with a PWA manifest and service worker. It also scaffolds Capacitor shells for Android and iOS, alongside a Tauri 2 shell for Windows, macOS, and Linux. The coding brain is Claude Code (using the Claude Agent SDK) for Claude models or OpenAI's Codex CLI for OpenAI models, running on your own sign-in or API key.
3. It tests its own app: The environment runs a type check and Vite build, then opens the app in headless Chromium across phone (390x844, touch emulation), tablet (820x1180), and desktop (1440x900) viewports. Any console errors, uncaught exceptions, failed requests, or an empty page fail the run immediately. The agent reads the screenshots of each screen size before it replies to you.
4. It ships: The web build publishes to appgnt.com/a/<slug>/ and is installable directly from the browser as a PWA. The first version usually lands in minutes.

Step 3 is the one that makes the rest work. The agent does not emit code and hope for the best. It loads the built application, checks for rendering errors, and evaluates its own visual output, so broken runs get caught and fixed before you ever see them.

What apps need that games don't

• Data stays on the device by default: Apps default to localStorage or IndexedDB. It is fast, works offline, and requires no account. A simple checklist or tracker should stay local.
• A backend only when the app cannot do without one: When you need accounts, data sync between devices, collaboration, secrets that cannot ship in client bundles, or tasks that run while the app is closed, the studio provisions infrastructure. It creates an isolated AWS CloudFormation stack containing a Cognito user pool, DynamoDB table, Lambda functions, and SQS queues. Requests only reach an app's resources by assuming that app's specific IAM role. Isolation is an IAM fact, not an application promise. Limits per app are capped at 12 collections, 4 queues, 8 functions, and 8 secrets.
• Exports, built on AWS Fargate: The studio builds installers on AWS Fargate, one task per export. It outputs Android debug and release APKs plus an AAB signed with a per-app key, Linux AppImage and .deb packages, and a Windows NSIS installer. Spike timings on the template: 197 seconds for Android, 50 for Linux, and 36 for Windows.
• The marketing kit and the app page: The studio automatically captures real screenshots of your deployed web app in a headless browser at store sizes. It generates icons, store art, and store listing copy within the exact character limits of Google Play and the App Store. It also publishes a page at appgnt.com/p/<slug> featuring download links, a generated privacy policy that Google Play and the App Store require, and a support form that emails the owner without either side seeing the other's address. You can see a live example with Water Tracker.
• Your own domain: You can point a bare domain or subdomain at your published app. Certificates are issued and renewed automatically.
• The MCP server at api.appgnt.com/mcp: Using OAuth 2.1 (setup instructions), assistants you already use like Claude, Claude Code, Codex, or Cursor can connect to your account. They can create apps, follow builds, edit files, run exports, and publish the app page. API keys and model sign-ins are deliberately not settable over MCP.
• You own the code: You get an ordinary React and TypeScript project alongside the generated Android, iOS, and Tauri projects, downloadable as a zip any time. The source and the builds leave with you; hosting of the web build and the backend are what stay with appgnt.

Honest limits

The first build is a working draft. Getting to the exact app takes a short, specific conversation.

iOS and macOS come as project zips with build steps because Apple builds need a Mac with Xcode.

Store submission is yours. You will need your own accounts, you will pay the fees (US$25 once for Google Play, US$99 a year for Apple), and you handle review. Push notifications also require your own Firebase or Apple accounts.

There is no Android emulator or Xcode on the build machine. The native lanes are wired by rule and tested at export, while the web build is what gets tested on every turn.

Small and specific beats big and vague. One job done properly beats an ERP.

Invite-only for now

appgnt is invite-only while I build it out, and there is no public price list yet.

If you want to try building an app with it, you can request an invite.

In the meantime, feel free to open Sprout and water a plant.

The marketing kit

This one started as an afternoon of manual work. I had an idle game in the studio, Nine Heavens Ascent, an 8-bit cultivation game with a one-thumb portrait layout, and I wanted it on Google Play. The build was the easy part. The hard part was the form: eight phone screenshots at 1080x1920, a 512 icon and an adaptive icon set, a 1024x500 feature graphic, a title under thirty characters, a short description under eighty, a long one under four thousand, the content rating answers, the data safety answers. Then an itch.io page on top, with its own cover size and its own settings.

I did it with Claude Code on my laptop: pulled the project down, had it capture the game in a headless browser, compose the framed screenshots and the feature graphic with the game's own fonts, and write both listings with the character counts next to each field. It took a couple of hours and the result was good enough to submit. That was the moment the feature became obvious. The agent inside the studio has the same project, the same browser, the same fonts and a much better view of what the game actually does. So the studio should do it.

What it does now

Every game's Publish pane has a Marketing kit section under the exports. Tick Mobile (Google Play and the App Store share one folder), itch.io, Steam, or any mix. Add notes if there is something the copy should mention or avoid, pick a model if you want one other than the game's own, and press Generate. The kit runs in the background like a build turn, in the game's own workspace, with a live feed of what the agent is doing.

The agent reads the project and writes itself a fact sheet, so every sentence of copy traces back to something the build actually does. It builds the web export if the current one is stale, opens it in a headless browser at every size the stores care about, and drives the game with scripted input: press start, hold right, tap here, screenshot. On the phone and tablet sizes it emulates a touchscreen, which matters more than it sounds: a game with on-screen controls shows them, and a responsive layout switches into its portrait form instead of being squeezed. It reads every frame it captured before keeping it. Then it composes the artwork at exact pixel sizes and writes the listings, counting characters as it goes. Before it finishes it re-measures every image against the store's size table, recounts the copy, and checks that the Steam screenshots are byte-identical to the raw captures they came from. The kit lands in the pane as a browsable folder, one per store, with a README that maps each file to the store field it belongs in, and a Download zip button for the lot. The Nine Heavens kit came to 120 files in ten minutes.

What it refuses to do

The part I care about most is the list of things it will not fake. Every screenshot comes from the playable build; concept art is never passed off as gameplay, and a layout the game does not have is never shown. Frostline GP is landscape-only, so its kit frames a landscape capture with the touch controls visible on a phone canvas, and its README says the portrait browser test was rejected and why. The copy claims gamepad support only if the input map binds a gamepad, touch controls only if they exist, online play only if the game has it; the same kit warns that the decorative ice pattern on lap one must not be captioned as damage. No review quotes, award badges, platform logos or prices end up baked into images. And the README names what the store still needs from you, a privacy policy URL for Play, a release keystore, a Team ID, measured PC requirements, instead of inventing them or leaving the submission form to discover the gap.

The trailer

Every Steam kit ends with a trailer plan: a 45-second beat list with timings, the exact inputs that produce each shot, a caption per shot, the copy cards between sections, the closing splash, and which of the game's own music tracks to use where. A finished kit then gets a second button, Make trailer, and the agent becomes the editor. The footage is not a screen recording. It copies the project to a scratch folder, adds an input script that plays the game frame by frame, and renders each shot with Godot's movie-maker mode: every frame at a fixed 30 frames per second with the game's real audio, however slow the machine is. Late-game shots are reached by playing. The Nine Heavens trailer needed a lightning trial and a reincarnation the plan had flagged as still unrecorded; the agent got there through the normal economy and said so in the trailer's README, next to a check that the project's 106 source files were untouched.

The cut has a fixed shape: gameplay from the first frame with a large caption over it, a caption on every shot in the game's title font, a full-frame copy card every two or three shots with a line drawn from the kit's own listing copy, and a closing splash with the key art, the logo and the tagline while the music resolves. Out come a 45-second 1920x1080 file for Steam, itch.io and YouTube and, when the game has a real portrait layout, a 15-to-30-second App Store preview recorded in that layout. The store specs and the trailer recipe live in a skill document the agent reads at the start of every run, not in its memory, so when Apple changes a screenshot size we change one file. The full write-up, with all three example kits, is on the vbgnt blog.

The MCP server

The second feature is the one that made the first one possible, in a roundabout way. The Nine Heavens kit was built by Claude Code on my laptop reaching into the studio to fetch the project and the builds. The way it reached in is now a product: vbgnt is an MCP server at https://api.vbgnt.com/mcp. Connect it from Claude, from Claude Code, from Codex, Cursor or any client that speaks the protocol, sign in once, and your own agent can create games on your account, send build instructions, follow the builds, manage your arcade, run exports, and now generate the marketing kit and its trailer, from wherever you already talk to it. "Make the store page kit for the kart game for Steam and mobile and send me the zip" is one sentence to your agent and forty minutes of waiting.

The tools are the same functions the studio's own buttons call, in four groups: games, arcade, exports and account. An agent that creates a game over MCP gets the same cloud machine, the same generated art, the same headless-browser test and the same publish to your arcade as a person typing the brief. Thirty-four tools in all.

The permission screen

I copied the scheme brokerages use for their agent connectors, because it is the one I would want if the account held my money. The server is its own authorization server. The agent registers itself, opens a vbgnt page in your browser, and that page names the agent, the account it will act as, and the permissions it is asking for. Allow is the only way in; there is no API key to paste. Tokens expire after an hour and refresh while the agent stays connected, so disconnecting the agent ends the connection. And two things are deliberately impossible over the wire: an agent can never set your keys or sign you in to Claude or ChatGPT. It can see that a key exists, so it can tell you what is missing, but keys are entered in the studio's Settings and nowhere else, because anything pasted into an agent conversation ends up in a transcript.

Setup for each client, with example phrases and the full tool list, is on vbgnt.com/mcp, and the reasoning is in the announcement on the vbgnt blog.

Why these two together

Both are about the studio being reachable from outside itself. The marketing kit takes the last manual jobs between a finished game and a store page, the screenshots, the copy and the trailer, and moves them inside the studio. The MCP server takes the studio and puts it inside whatever agent you already use. The studio is still invite-only; you can ask for an invite here.

A dream

You describe a game in a paragraph: the kind of game, how it plays, how it looks, what it should feel like. An agent writes a production bible from that: the world with named places, the rules of play, two to four characters with repeatable visual descriptions, and a director's prompt that says all of it in the present tense. It paints a reference image for every character and key place and composes an opening shot. Then a realtime video model films the movie in short clips, keeping the cast and places consistent from prompts, and every clip it asks what you do next. You type it or say it, and the next scene is shot around your answer.

The thing I got wrong first was caution. My live director was told to protect the fiction, so when a friend typed "take out a machine gun and start blasting" in a medieval battle, the film politely refused. That is exactly backwards. In a dream your direction is law, and now it is: absurd, genre-breaking, whatever. The world bends to it.

A super dream

The weakness of a plain dream is that nothing underneath it is true. There is no position, no health, no door that is either open or closed. The video model remembers a few sentences and improvises the rest. A super dream fixes that the blunt way: it puts a real game underneath the film.

The studio builds a small Godot game with deliberately crude graphics, coloured shapes on a flat background, and real mechanics. A bridge inside the game reports what is on screen several times a second and composes a prose description of the current shot. Every clip, that description becomes the director's next prompt. No language model sits in that loop; the game already knows what is happening, so it just says so. The film trails the controls by seconds, and rather than hide that I draw it: a wireframe layer over the film marks where the game says everyone is now against where they were when the playing clip was shot, with a badge that says how far behind the film is.

What breaks

Plenty. A session runs about two minutes before the stream stops and you continue from the last frame, so a story arrives in chapters. A move takes seconds to reach the screen. A plain dream has no world state, only the last few beats as text. The film mostly agrees with the bible about the colour of a coat, and sometimes does not. And every second of film is metered, which is why the thing is invite-only and why every session is recorded and public: a played dream is worth more watched than filmed once.

Why bother

Because of what changes if it works. A game engine needs every asset made in advance. A video director paints from a description and a reference image. If that holds up, the expensive half of making a game stops being expensive, and what is left is the interesting half: the rules, the state, the choices, the pacing. The super dream is a first sketch of that split. The game is shapes and rules. The film is the look.

The dreams played so far, with every session recorded and every move captioned, are on dream.vbgnt.com. The longer write-ups are on the vbgnt blog: what a dream is, how a super dream works, and the alpha notes. Watch a few. Then imagine the lag at zero.

Online multiplayer, from one sentence

The test case was a game I already had in the studio: Hockey: Tactics, a turn-based hockey game, X-COM style, where you spend action points to skate, pass, shoot and body-check on a gridded rink. It was single player. I typed one message into its conversation:

ok we just added multiplayer module to our system can you add it to this game!

Not a great prompt, honestly. It worked anyway. The agent built a lobby in the game's own art style and rewired the match so one player's browser runs the game and the other's sends moves to it. Then it opened two headless browsers, hosted a room in one, joined from the other, and only finished the build when both screens showed the same rink.

This is how it works for the player. One person presses Host and gets a four-letter room code plus a Copy link button. The other types the code or opens the link. The match runs browser to browser, so there is nothing to install and no account to make. Rooms hold up to eight players, and games built for online play get an Online badge on the arcade.

Try it: open Hockey: Tactics on the demo arcade in two tabs, press Host in one and Join with the code in the other. Or send the second tab's link to someone across town. It plays on a phone too.

The platform side of this is deliberately small. Godot already ships a good multiplayer engine; vbgnt adds only the meeting point, a room service that hands out codes and introduces the two browsers to each other, and the agent learns how to use it from a skill document. The hockey game was the first time it had ever seen that document, and it got the lobby, the host and guest split, and the test right on the first turn. This first version is built for playing with people you know: no matchmaking, no accounts, and if the host closes the tab the match ends.

Export anywhere, publish to itch.io

The second feature is the one I expect people to use more often. Until now a vbgnt game lived on your arcade as a web build, and getting it anywhere else meant downloading the project and running the engine's exporter yourself. Every game in the studio now has a Publish pane, next to Game and Files, that does the whole job on a dedicated build machine.

What you get for each platform

• Web: the same build the arcade plays, zipped with index.html at the root, which is exactly the shape itch.io's upload form wants.
• Windows and Linux: single-file binaries with the game data embedded. Download, run.
• macOS: a universal app, ad-hoc signed so it launches on Apple Silicon without the "damaged" error. It is not notarized, so a downloaded copy shows the unidentified-developer prompt until the player right-clicks and opens it.
• Android: an arm64 APK signed with a debug key. Fine for sideloading and for itch.io; Google Play wants your own release keystore.
• iOS: an Xcode project with your Team ID and bundle identifier filled in. Archiving the .ipa needs Xcode on a Mac, which no Linux build machine can do, so this is the one platform the pane exports but never pushes.

Tick the platforms you want, press Export, and go back to working on the game. The build machine mirrors the project as last saved, runs the Godot export for each platform in turn, packages the results and lists them with download links in the same pane. A full six-platform job takes about ten to fifteen minutes; web on its own is a couple of minutes. Each export gets a version number the studio increments for you, so the Android version code and the itch.io version string stay in step without anyone thinking about it.

The itch.io push

This is the part that turns an export into a release. Save an itch.io API key in the studio settings once. On itch.io, create the project page and note its slug. Then in the Publish pane tick Push to itch.io, enter the target as yourname/your-game, and press Export. After each platform finishes, the build machine pushes it to the matching channel on your page with butler, itch.io's own upload tool: html5 for the web build, then windows, mac, linux and android. The pane shows each channel's status next to the platform row and gives you an Open on itch.io link when the push is done.

Two things to do on itch.io after the first push, both once. Set the project kind to HTML so the page gets a play button, and tick "This file will be played in the browser" on the html5 upload. After that, every later release is the same click in the studio: ask for a change, wait for the build to land on your arcade, press Export. Because butler pushes only what changed between versions, a re-release of a big game is a small upload.

Multiplayer games export like any other. The web build plays online exactly as it does on the arcade, and the desktop and mobile builds get the native networking library added during the export, so a friend on the Windows download can host a room and you can join from the browser on your phone.

Where the stores fit

The export gets you to the store's front door, not through it. Steam wants the desktop builds uploaded through its own pipeline and a $100 Steam Direct fee; Google Play wants the APK signed with a release keystore you own; the App Store wants the Xcode project archived and signed on a Mac. The vbgnt blog has a guide for each. itch.io is the one place the studio can finish for you, which is why it is the one wired into the pane.

See who played

The third feature is the one I had wanted for myself the longest. An arcade is a link you send to people, and until this week the only way to know whether anyone opened it was to ask them. Now the studio shows a panel above your games: views of the arcade page, distinct players per day, games started, and total playtime, over the last 7, 30 or 90 days. Under it, a daily chart, your five most played games with playtime each, and a split by where the plays happened. Every game card in the grid carries its own small play count too, which is what finally made reordering my shelf a decision instead of a guess.

The part I care most about is where the numbers come from. Two things report in and they never overlap. The arcade page counts its own views and the games it launches, and when a game closes it sends how long the session ran. Everywhere else, the game counts itself: every build the studio makes now carries a few dozen lines that report one play when the game boots outside the arcade page and a slice of playtime every couple of minutes while it runs. That is how a game opened from a link pasted into a group chat gets counted, and it is how the Windows, macOS, Linux, Android and iOS exports from the Publish pane get counted, each labelled with its platform. Inside the arcade page the game stays quiet, so nothing is counted twice. My own previews in the studio are ignored, and so is the headless browser that tests every build.

Just as important is what it does not do. There is no third-party analytics script, no cookies, and no consent banner. To tell a hundred people from a hundred reloads, each visitor is reduced to a hash of their address and browser that changes every day, so nobody can be followed from one day to the next, and the hashes are discarded within days. There are no per-player profiles and no list of who played. And nothing is public: the arcade page shows no counts and ranks nothing by them. I wrote about why the arcade has no feed when I built it, and a public play count is a feed by another name. The panel is for the maker. The write-up with the full list of what it refuses to collect is on the vbgnt blog.

Why these three together

Until now a vbgnt game was something you sent to a friend as a link. Now it can be something you play with them, something you put on a store page with a price on it, and something you can watch find its audience. All three features are about the game leaving the studio and you still knowing what happened to it. Everything before this was about getting it built.

More detail on each is on the vbgnt blog: how the export pipeline works, publishing on itch.io step by step, how online play works, and how the arcade counts plays without tracking anyone. The studio is still invite-only; you can ask for an invite here.

I've changed my mind. It's a product now: vbgnt.com.

You can play the output right now

The fastest way to understand it is to go play something. Three games are up on the demo arcade at demo.vbgnt.com. No install, no account, they just open in your browser:

• Frostline GP, two-player split-screen kart racing on a frozen lake under the aurora. The ice fractures along every line you drive, so the fast groove from lap one is a death trap by lap three. Drift to charge boost, release to fire.
• Static Garden, a first-person walk through a garden made of light that only rewrites itself where you are not looking. No combat, no fail state; seven blooms to reach by deliberately turning away from them.
• Ember Hollow, a pixel-art puzzle-platformer about descending a cavern carrying the only light. You can hold the lamp or use your hands, never both. Set it down to climb, pull levers in the dark, then come back for the glow.

Each one started as a sentence.

What changed

The thing that kept the original build personal was the IP problem. My prompts were all "what if Mario Kart but with classic movie monsters," and the models were happy to oblige, somewhere between refusing outright and handing back a pixel-perfect recreation, with a detour through calling things "Wobbly Space Bears" to get around their own blocks. That's a fun toy and an unshippable product.

So the brief changed. You describe the game you want in your own words: a genre, a feel, an era, the one mechanic you actually care about. What comes back is an original game built to that description. A kart racer on a frozen lake. A one-button climber with a collapsing wall. A puzzle where stacking light is the mechanic. Turns out the interesting part was never the borrowed characters; it was the fifteen minutes.

What's underneath

Roughly the same machine as the personal version, hardened and pointed at other people:

1. You describe it. One sentence is a complete brief. A paragraph and a pile of reference images works too.
2. The agent builds it. A cloud microVM boots with the whole toolchain on it: Godot, the coding agent, generative 2D and 3D asset pipelines. It writes the code, generates the art and audio, and wires up touch, gamepad, and keyboard input. A real project, not a snippet.
3. It plays its own game. Before you ever see the build, it gets loaded in a headless browser and driven: does it boot, does it hold framerate, does anything throw. Failures go back to the agent, not to you.
4. It ships to your arcade. The web build publishes to yourname.vbgnt.com. Send anyone the link and it opens on their phone, their laptop, or the browser on their TV.

Step 3 is the one that makes the rest work. The agent isn't emitting code and hoping. It opens the game, plays it, and reads its own console errors, so most of the failures never reach a human.

Invite-only for now

It's invite-only while I build it out. Request one and you'll get a single email when it's your turn. In the meantime, go crash a kart into some ice.

Games are prompted in a simple chat interface and then generated in a cloud development sandbox.

Each game gets what amounts to a disposable game-dev workstation that materializes on demand: a cloud microVM booted from a Docker image containing a full Godot install, the AI coding agent, generative 2d and 3d art asset pipelines, and a headless browser for playtesting.

The agent harness makes sure the game works well across all platforms, including providing on screen controls for mobile phones and gamepad support for televisions and desktop. The game library is presented through a SteamOS/Netflix-esque launcher interface.

Fable 5 provides the brains of the agent and is the first model I have found that can produce quality games with very little prompting back and forth. (one-shotting as they like to call it). It is eerily good at creating games based on existing games, it's particularly good at kart racing games and Vampire Survivor-esque games. It is also surprisingly good at recreating old 90s Bullfrog and Sega-CD FMV games.

Now as you can see this thing is an absolute trademark and copyright nightmare. Fable 5, gpt-image-2, and Meshy all have varying levels of pushback on generating assets “inspired” by copyrighted materials, from flat out refusing on some IP, to generating pixel perfect recreations for others. The models also try to get around IP blocks using descriptive language like “Wobbly Space Bears”. For this reason this product is not something I am seeking to commercialize and is fully for personal use!

But the concept of a personalized entertainment system that can create custom content based on the user’s ideas or interests is closer to reality than we think.

This project proved to me that the future of media isn't just curation; it's instant creation. We are rapidly moving toward a world where the line between player and creator completely dissolves. Imagine a streaming platform that doesn't just recommend a sci-fi thriller, but generates a bespoke interactive experience based on your exact mood that evening.

The legal frameworks around IP will take years to catch up, but the underlying tech stack is already here.

Update, August 2026: I said above that this wasn't something I was looking to commercialize. I've changed my mind. I worked out an approach to the copyright and trademark problem, so the dream console is now a real product at vbgnt.com. Describe a game, and an agent writes it, draws it, builds it, opens it in a browser to check it actually runs, and publishes it to an arcade that's yours.

Inspired by Andros's excellent write-up on joining the IndieWeb, I implemented the full stack:

• Microformats2 everywhere: an h-card on the homepage, h-entry on every post, and a proper h-feed.
• Webmentions, sent and received. Link to one of my posts from your own site and it shows up below the article.
• Micropub + IndieAuth, so I can publish from any Micropub client by signing in as frankrobles.com.
• WebSub, so feed readers get new posts pushed in near-real-time instead of polling.
• RSS + JSON Feed, because feeds never stopped being great.
• rel="me" identity links to my other profiles.

Under the hood it's a static site: markdown in S3, a tiny custom generator running in Lambda, published to S3 behind CloudFront. The dynamic endpoints (Webmention, Micropub, IndieAuth, and a WordPress-compatible posting API) are a single Lambda function behind the same domain. No servers to patch, and the whole thing costs pennies a month.

More on the architecture in an upcoming post. If you have a webmention-capable site, try linking here and it should appear below.

The client list is stranger than expected: Claude and ChatGPT, Claude Code and Codex, of course, but also surprisingly Manus and fully home-built agents, including a custom calendar monitor someone wired up without ever contacting us.

Notably absent: OpenClaw, despite all the noise.

What agents do with a calendar turns out to be mostly watching it, briefings and availability checks, with one agent monitoring calendars around the clock.

When they act, it's real work: events, syncs, and booking pages created entirely from chat. For some users the dashboard has become optional.

Our favorite pattern: users pointing their chat assistant at our AI scheduling assistant and letting them negotiate. Agents delegating to agents.

Build to the protocol, not the platform. The agents find you.

All paid CalendarBridge users can connect any MCP-capable assistant.

CalendarBridge

Originally posted on LinkedIn on 2026-07-23.

Here's the usual state of things. One calendar has the real meeting. Another has a manually copied block. A third confidently reports you as free. Then someone sends you a scheduling link offering a slot you booked two days ago. Very productive.

The requirement sounds trivial: change something in one calendar and every other calendar reflects it: quickly, without merging accounts, without exposing meeting details.

Then reality shows up: recurring events, cancellations, time zones, privacy rules, separate tenants, and three vendors who each interpret "calendar standards" a little differently. Congratulations, your productivity hack is now a systems integration problem.

The teams that win at scheduling won't be the ones with one more calendar app to check. They'll be the ones whose availability is simply correct inside Google Calendar, Outlook, and Apple Calendar, where they already work. No calendar archaeology required.

That's the boring problem we've spent years solving at CalendarBridge. Boring, of course, until your calendars disagree about where you're supposed to be. #CalendarSync #GoogleCalendar #MicrosoftOutlook

Originally posted on LinkedIn on 2026-07-16.

Bring Your Own Agent

Between then and now many new agents have sprung up: OpenClaw, Hermes, Codex, and Claude Code have quickly become some of the most adopted agent harnesses on the market. Everyone has their preference and opinion about which works best and which model work best. We want to allow our users to harness the latest models and agents to manage their calendars and CalendarBridge accounts, so we are releasing the CalendarBridge MCP server.

The CalendarBridge MCP server lets you manage all of your calendars directly from your agent of choice. Your agent will now have access to all of your Google, Microsoft, ICS, and Apple iCloud calendars. Have your agent find free time across your calendars, create deep work blocker events, and reschedule events. Have your agents run weekly tasks like sending you your schedule for the week on Monday mornings or look for double bookings.

CalendarBridge Account Where You Need It

Besides calendar management the server will also let you manage your CalendarBridge account with access to all of our features. You can sync all of your primary calendars, create one off booking links, and add more calendar accounts, all from your agent. This unlocks a lot of interesting use cases. I had Claude build a dashboard of my CalendarBridge account that looked a whole lot like our recent user portal redesign. 🤫

Agent-To-Agent (Agent Inception)

Our AI assistant is not going anywhere, in fact, it is part of our MCP server. That's right, you can now dispatch your AI scheduling agent from your agent of choice. This unlocks powerful use cases where scheduling tasks get delegated to a more purpose built agent freeing up your general purpose agent to get other tasks done for you (and save money on tokens in the process).

Security

Our MCP server follows all best practices and provides fine grained permissions so your agent can never perform any tasks without your explicit permission. All tool calls are annotated with their access control levels and provide detailed information to the agent on what the tool call can and can’t do.

Build it yourself? Build it yourself!

“SaaS is dead.” “Why not just use OpenClaw?” “We’ll just vibe code it.”

My answer to all of these is GO FOR IT. But if you need a rock solid, secure calendar syncing and management API for your agents, I recommend using our industry leading platform as a foundation for your calendar integrations.

CalendarBridge

Originally posted on LinkedIn on 2026-07-09.

1. Recurrence rules will take up more of your time than you expect. A single repeating meeting expands into RRULEs, exceptions, cancellations, and moved instances, and keeping all of that consistent across platforms is where a lot of sync bugs live.

2. Privacy controls are not as simple as they sound. They turned out to be complex enough that we ended up with a patent for our approach: https://lnkd.in/eV_RufaN

3. Google, Microsoft 365, Outlook, Apple iCloud, and .ics files all share the same core calendar concepts, but they interpret them differently. A lot of it traces back to iCalendar (RFC 2445, published in 1998: ietf.org/rfc/rfc2445.txt) and CalDAV (https://lnkd.in/eVhrh-MP), and every platform has its own quirks layered on top.

4. Time zones are still a problem. Daylight saving time is still a problem. Anyone who tells you otherwise has not had to debug calendar sync for real users.

5. Event ownership matters. If you are not the organizer, there are real limits to what you can change, accept, or decline, and each platform enforces those limits differently.

6. Tentative meetings are their own category. Whether they block availability depends on how the user, the admin, and the calendar platform are configured, and those three rarely agree.

7. API rate limits, permission scopes, and third-party service reliability are not theoretical. They decide what your product can actually do at scale, especially once enterprise tenants and security teams get involved. The rate of sporadic failures in services people assume are "just working" is higher than most people realize.

8. End users will find the edge case you missed, usually within minutes of a new feature launching.

9. The simple version of calendar sync is easy to demo. The reliable version is a product.

10. Every new feature means re-running the full regression matrix. With multiple platforms, recurrence patterns, time zones, and permission setups, the number of test cases multiplies fast, and a change that looks isolated can break sync behavior three providers away.

11. There are a lot of vibe-coded calendar sync solutions out there now, and some of them actually almost work. What they don't have is years of hardening from real user behavior at scale, and they are certainly not certified for the kinds of secure environments we work in.

If all of this sounds boring, that is the point. The best infrastructure is boring when it works.

And if you just want your client, work, and personal calendars to stop fighting each other, that is what we built CalendarBridge for.

#CalendarSync #SoftwareEngineering #CalendarBridge

Originally posted on LinkedIn on 2026-07-02.

Originally posted on LinkedIn on 2026-04-01.

1. Sorry, you are going to need to run this on some kind of Apple hardware, whether a Mac mini or an old Apple laptop you have lying around. It works best out of the box with mac specific CLI programs like peekaboo and is able to do many desktop activities easily via things like applescript and having access to OS level accessibility. Being able to remote desktop into your OpenClaw machine to see what it is doing, as well as help it along when it gets stuck is also necessary.

2. The only model that can actually accomplish complex tasks right now is Claude Opus 4.5. You are going to want to use an API key from Claude to avoid the rate limiting that the subscription based access gives you. This is also very expensive!

3. Create (or have your agent create) its own gmail account. This way it can sign up for other sites that have email verification and anti-bot measures (which the agent can correctly identify and get around!). This also lets it send emails.

4. Don't bother with the chrome tab control extension and just have the agent operate its own browser instance. You can log into whatever accounts you have on this browser instance so it can do various things on your behalf but read 5 first!

5. Do NOT give your agent access to any sensitive information or accounts you have. This is still experimental software and you should not trust it with access to ANYTHING critical.

6. Telegram is the easiest messaging channel to set up currently and works across all of your devices, this also lets your send and receive voice messages (tell your agent to reply with a voice message and it will figure it out!)

7. Any recurring tasks included in the HEARTBEAT.md file will be very expensive so keep these to a minimum.

8. Enable nano banana support and give it a gemini API key so it can generate images. This is useful for having it create avatars for various services as well as post images to any sites you might want it to.

9. Set your expectations low for the kind of tasks it can accomplish. There are a lot of posts claiming amazing results with OpenClaw, some are completely fabricated, some are actually accomplishable with a little effort. Some things I have successfully had it do: sign up for and post on reddit, sign up and post on twitter, generate a voice summary of the days news, send and check emails. Some advanced things I had it do: sign up and post about 80s movies on https://moltbook.com. Perform a few bounties on https://shippy.sh/ . See 10 before trying these!

10. Be wary of any sites that ask you to add a skill.md link to your agent. You are going to want to follow the link and review what exactly the site is trying to instruct your agent to do.

If none of this post makes sense to you, but you would still like to experience what all this agent stuff is about, you can try our secure email based scheduling assistant at https://lnkd.in/e6B2RKRw ;)

Originally posted on LinkedIn on 2026-02-04.

The scheduling assistant can tackle any scheduling task simply by cc’ing it on an email thread or emailing it directly.  The agent can handle booking, rescheduling, and cancelling meetings, letting you focus on more important work.  It can also perform more complex tasks like rescheduling entire days of meetings, accepting/declining pending invites, and following up on threads that may have gotten lost in the shuffle.  I have been finding new tasks it can perform almost daily including taking lunch orders and performing user feedback surveys.

Cross platform support  The assistant supports all major calendar platforms: Google, Microsoft/Outlook, and even iCloud calendar accounts. You can add up to 3 calendars from your other accounts to use for availability.  It also supports video conferencing with Teams, Meets, and Zoom.  

Natural Language Configuration  You can adjust tone, give it a name, set working days and hours, add meeting types and locations, and give it complex rules for following up all using natural language.  I like to call this feature “normie programming” because of the flexibility it provides. For example, I have my own assistant asking all attendees to answer trivia questions about pirates before being able to schedule a meeting.

Dynamic follow ups  The assistant will follow up on email threads with anyone who hasn’t reponded.  You can fully configure this behavior with waiting time and frequency, but the assistant will also pick up on things like out of office autoreplies to follow up when the person is available.

Organization Support  Every employee in your organization can have their own assistant that knows the availability across your organization and tenants.  Five minutes of configuration is all that is needed to deploy across your organization. Individual employees can also have their own custom configurations.  (Google Workspace, MS O365)    It's been a long time since I had an experience using a product that legitimately felt like “magic.” Even less frequently with something I have actually written the code for, this product surprises me almost daily with its flexibility and seemingly endless tasks it can perform.  I think people collaborating with agents to get work done will be the norm in a few years, and I am looking forward to what we have planned for the near future to bring that goal closer.

https://lnkd.in/e6B2RKRw

Originally posted on LinkedIn on 2025-07-15.