Designing the interface layer for an agentic content engine

The interface between agents and the people who use them

A US verification-services company wanted its engagement content — scripts, videos, blogs, campaigns, even website changes — generated by AI agents, grounded in brand-voice and customer-profile files rather than anyone's memory. My job was the layer between those agents and the people using them: sales and marketing reps who are not prompt engineers and should not have to be. Growth OS is agentic end to end; the interface is what makes that safe and usable.

The brand lives in files

The premise: brand voice and customer profiles live as markdown files authored by the client, and every agent output is generated against them. The design consequence is that reps never write prompts. The interface collects intent — audience, goal, channel — and lets the context files do the rest.

This is a meaningful inversion. Most AI-product interfaces put the burden of grounding on the user: the better your prompt, the better the output. Here, grounding is structural. The files are the prompt layer; the rep's job is to steer through a surface designed for the task, not to engineer language. Monika's contribution is that interface layer — not the content of the markdown files themselves, which are client-authored.

Two surfaces, split by task geometry

Not chat everywhere, and not wizards everywhere. The two input surfaces exist because two fundamentally different task shapes are in play.

Content journeys — scripts, blogs, videos, campaigns — are repeatable with knowable steps. The inputs that matter are predictable: who is the audience, what is the goal, which channel. A wizard gets that brief right the first time and gives the agent the structured context it needs. Website changes are unbounded point-edits: "change the hero line," "swap that testimonial." Those edits resist pre-structuring into a form — the rep knows what they want, but the range of possible requests is too wide to enumerate. Conversation fits. The same reps use both surfaces; the split is about task geometry, not user type.

The revision loop

The rep never accepts or rejects wholesale. They steer. After the agent produces a draft, the rep gives revision notes and the content regenerates. The rep then chooses between variations rather than editing freeform — the agent does the rewriting, the rep does the evaluating.

Favorites persist as future reference, so the system's outputs converge on what the team actually likes over time. That is preference learning through interface, not through prompt tuning. For video specifically: after selecting a variation, the rep picks an avatar, then schedules or posts directly to social media.

An agent that can touch the website needs a hierarchy

The highest-stakes capability gets the strongest controls. A rep describes a website change in chat; the agent proposes options; marketing chooses; admin approves; only then does the site change. The agent can generate anything. Humans control what gets published, and who gets to approve what is determined by role.

The whole application is role-based. Reps propose, marketing selects, admin approves. This is not a guardrail bolted on after the fact — it is load-bearing for the product's trustworthiness. An agentic system that can touch live infrastructure needs a human hierarchy with clear authority at each step.

Working directly with engineering

Sole designer, five engineers, no PM in between. Requirements, feasibility, and interface contracts were negotiated directly in build. The agent's output structure and the UI that renders it evolved together — there was no handoff phase where specs were passed over a wall.

This close coupling meant the design could be responsive to what was actually buildable in the moment, and the engineering team's domain knowledge of what the agent could produce shaped what the interface promised. The tradeoff is that documentation discipline has to compensate for the absence of a PM buffer: decisions made in conversation need to be captured explicitly.

In build

Growth OS is in active development. Success will be measured on rep adoption — whether the reps who were supposed to use this actually do — content shipped through the system relative to what was produced manually, and time-to-publish versus the previous process. Those are the metrics that matter. None of them exist yet.

What I'd push further

The failure and uncertainty states are the next design problem. Reps can flag a bad output; there is a loader animation during generation. That covers the surface-level cases. What is not yet designed is how the interface should behave when an agent is unsure, off-brand, or wrong before a human catches it — how uncertainty gets surfaced before the rep invests in a revision loop on content that was never going to work.

Richer failure states — beyond flagging and loaders — would make the system more honest about the limits of what the agents can do. That is the design work I would want to do next.