Consider providing a compact, agent-friendly authoring layer for Bento Slides #411
Replies: 2 comments
|
Some way to compress the document JSON is something I was exploring so this is really timely. I particularly appreciate the poc implementation. Will test this over the weekend and see how we can incorporate this in the next release. From what I can see, we should be able to add this ability to the runtime quite easily and without much adding much size. Thanks for taking the time to put this together and the feedback! |
|
This is in 1.2.0, out now, and your proof of concept is the shape it took. A document can carry |
Uh oh!
There was an error while loading. Please reload this page.
Context
Bento Slides is explicitly designed to be authored and edited by AI coding agents. The
AGENTS.mdguide is intended to be provided to agents such as Claude Code, and the documented file-harness workflow has the agent edit the JSON inside the#bento-docblock directly.This works, but the JSON representation is quite verbose for an LLM to author. A large amount of the generated output consists of repetitive structural/default properties rather than information that is meaningful to the author.
For example, even a simple text element normally carries fields such as:
Original JSON text element
{ "id": "title", "type": "text", "x": 96, "y": 100, "w": 1088, "h": 100, "rotation": 0, "opacity": 1, "html": "Hello", "fontSize": 48, "fontFamily": "system-ui, sans-serif", "fontWeight": 800, "color": "#111", "align": "left", "valign": "top", "lineHeight": 1.1 }Much of this is boilerplate. It becomes particularly costly when an agent is generating a deck with dozens or hundreds of elements.
A small proof-of-concept
I built a small TypeScript authoring harness for my own use.
bentoUtils.ts
The basic idea is to let the agent write a more compact authoring representation and compile/normalize it into the existing Bento document format. It currently provides:
For example,
applyElementDefaults()allows an author to omit properties that have known defaults:The helper fills in the repetitive defaults and produces the normal Bento JSON representation. I also have helpers for common structures:
This isn't intended to hide Bento's document model. The generated result remains normal Bento JSON; the TypeScript layer is simply a more compact authoring representation. For example,
createCard()can produce the background, kicker, title, and body elements as one authoring operation, while still producing ordinary editable Bento elements with deterministic IDs.This utility was built purely from observing the provided
AGENTS.md; I haven't looked into Bento's internal implementation. The motivation came from using ChatGPT to author a Bento slide and observing that it wrote a Python script to generate repetitive elements. I realized that a small reusable authoring layer could solve the same problem more directly.Why this matters particularly for AI agents
For a human, repetitive JSON is mostly an inconvenience.
For an LLM, it has additional costs:
This is particularly relevant during iterative editing, where the agent may repeatedly need to read and modify a large document.
The current
AGENTS.mdworkflow effectively asks an agent to author directly in the canonical document representation. A compact authoring layer would let the agent work at a slightly higher level while preserving the same underlying Bento model.This could be better coming from upstream
I haven't looked at the TypeScript code that comprises Bento's internals, so I don't know whether this is best implemented inside the runtime, as a companion package, or as part of the agent skill.
However, the documented Bento element schema already provides a sufficiently structured foundation for building a compact authoring layer on top of it.
Such authoring aids could take several forms:
The important distinction is that the storage/runtime representation does not necessarily need to change. The compact representation could simply compile into the existing
bento/slidesschema.In one particular Bento slide I worked with:
So the TypeScript authoring source was roughly half the size of the generated JSON, while also expressing some structures at a higher level rather than merely omitting defaults.
The
Meeting260810.tsis a 11 slide Bento slide that consists of structural code such as:I'd be interested in whether this is something you'd consider supporting officially, or whether there is already a preferred approach for compact, agent-oriented Bento authoring that I have missed.
All reactions