AI in the editorial experience: early experiments with AGUI

A university asked us to help reduce the friction in their editorial workflow. Their editorial team was producing a lot of content — course descriptions, faculty bios, research summaries — and a lot of that content was repetitive. The same person was writing five variants of the same description, swapping out names and dates. It felt like work that a language model could genuinely help with.

We started with the assumption that we would build something that would generate text in the browser and let editors refine it. Three weeks in, we had built something weirder and more interesting.

The setup

We chose AGUI (AG Grid UI) because it is a genuinely sophisticated data grid component library, and a lot of what editors are doing is grid work — creating rows of content, comparing variants, making small adjustments. AG Grid has built-in features for bulk editing and rendering custom cell types, which meant we could embed AI tools directly in the grid without rebuilding the whole experience around them.

The editorial interface is still Drupal’s node edit form for structured fields, but we added a panel next to it showing a grid of similar published content. An editor is writing a new course description, and they can see five published descriptions side by side. That context alone reduces a lot of the friction.

What felt right

The first thing that worked was real: offering editors suggestions without disrupting their flow. Instead of “click here to generate text,” we wrote a cell formatter that runs an AI API in the background and shows the result as a suggestion. The editor sees both the published version and a suggested variant, side by side. They can take it, adapt it, or ignore it.

For course descriptions, this was genuinely useful. The AI would read the existing description, see similar courses, and suggest a variant. Not perfect, but directional enough that an editor could refine it in five minutes instead of writing from scratch.

The other thing that worked was letting editors see failures. When the API was slow or the model returned something unusable, we showed that as a failure state in the grid. Not silently falling back, not just spinning forever. An editor would see “AI suggestion failed — try again” and could make a decision about whether to wait or write it themselves.

What felt creepy

The original pitch included a “bulk generate” button that would fill a column of suggestions for every row at once. I pushed back on this. It felt like automation-at-scale without a safety gate, and the safety gate here matters.

Here is the honest version: if you make it too easy to generate content, you end up with a lot of generated content. That content might be fine. It might also be superficial, stereotyped, or wrong in ways that are hard to spot until a student reads it or a parent sees it. A university’s institutional voice has to come from people. AI can help with the repetitive parts. It should not replace the human decision about whether a piece of content is actually good.

We built a “suggest next” button instead — generate one suggestion for one row, show it to the editor, let them decide if it is worth using. That slowed things down compared to bulk generation, but it created an interface where the editor’s judgment was structural, not optional.

The other creepy part was the temptation to try to be clever about what the AI learned. We had access to the editorial history of similar content. There is probably a model in there about what makes a good course description at this university. We did not build it. That felt like territory where one wrong move — a model that learned that certain departments describe courses differently, or that certain topics get written with more sales language — would be a problem waiting to happen.

What we’re still figuring out

One thing that surprised me is how much the form of the suggestion matters. When the AI returns text, we show it in a read-only cell next to the published version. An editor can click “use this” to copy it into their working document. But I wonder if a different UI — maybe the suggestion appears as a comment on the existing text, or as a diff-view — would feel less like “replace your whole text” and more like “here’s a sentence you might borrow.”

The other thing I am uncertain about is how this scales to different types of content. Course descriptions have a lot of structure — they all need the same information, in roughly the same order. Faculty bios have more personality. Research summaries need accuracy in ways that course descriptions do not. We got it working for structured, repetitive content. I am watching to see whether the pattern holds when the content gets weirder.

The last thing is the question I did not anticipate: what happens when the university wants to audit the AI suggestions? If an article was generated with AI help, the university probably needs to know. We added metadata to track “this field was edited with AI assistance,” but what happens with that metadata is still an open question. Does it appear in the editorial interface? The published page? Is it something only the university cares about, or should the reader know?

For now, it is working quietly. Editors are using it. Descriptions are getting written faster. The content is still getting reviewed by humans before it goes live. That feels like the right place to be — AI as a tool that makes work faster, not a replacement for the work.