Document Automation

Templafy already had a document agent that could generate brand compliant presentations from a prompt. There was no admin setup or configuration. The only interface was a prompt field in the end user experience.

The agent handled styling well, but the content came only from the prompt. It did not use existing company materials. If someone needed a specific slide from the company library, the agent would not retrieve it. It would generate something new using the right layout, but not the actual source content.

The universal agent's only interface: a prompt box in the end-user experience.

For generic presentations, that worked. For specific and repeatable document types like proposals, sales plays and executive reviews, it did not. Customers needed agents that behaved the same way every time, using slides their teams had already approved.

This called for a different kind of product. Admins configure custom document agents once, and employees use them after.

The agent already had a menu entry in the admin center and a working list view for published agents.

Creating a new agent opened a fixed two step wizard. It started with name and description, then ended in a full screen modal that tried to show details, questions and a section outline in one view.

Templafy already had centrally managed AI assistant settings and knowledge source configuration. These could be reused in custom document agents.

Layout guide was already in development. It reused full presentations and individual slides from the library during document creation. Custom document agents used the same pool of approved content.

The configuration model needed to align with these existing systems.

The work focused on extending current admin setup patterns and applying them to each document type.

Five enterprise customers joined a private preview to co-develop the feature. Monthly task-driven sessions ran with their subject matter experts, the people who build these documents. I led the design portions: presenting the solution and capabilities, and running prototype and design feedback with admins.

A pattern surfaced early. No one started from scratch. They opened a service blueprint: a repeatable document listing what sections belonged in the proposal, which slides filled each section, and what the finished output should look like. Following the blueprint and dragging slides from the library produced 80% of the proposal before a word was written.

The agent did not need to reinvent how these documents got made. It needed to follow the blueprint customers already had.

I picked two approaches to test. Chat, because the industry was moving towards conversational interfaces and our CPO was advocating for one. A panel with manual setup, as the contrast. Testing both in the same round surfaced which parts of each worked, and informed what features the product needed.

Both pointed at the same thing: admins look at a document by its structure first. Configuration comes after.

Testing informed the scope. We chose to prioritise reusing slides from the library as the core of section-level configuration, with AI generation, input questions, and knowledge sources around it.

Two more expectations surfaced in sessions.

• Admins did not want to configure each section from scratch. With enough context, they expected the agent to draft an initial setup with instructions and proposed library slides, then review and adjust.
• They expected slide previews in a PowerPoint format. This did not hold. Section output varied based on generation and library search. Slide search was variable based on the number of matches. Slide count became variable.

This led to using content rows instead of slide previews.

This surfaced in the first round of testing.

Library organisation varied across customers. It depended on the admin's role and whether maintaining the library was part of their job.

One customer, a specialised executive search firm, maintained 16,000 slides organised by industry and role. Each service line owned its folder and kept it current. Slides had enough metadata for the LLM to match section requirements to the right content. Others had a few folders, repeating slide names and slides used for layout rather than content, with little or no metadata.

The same agent, used on different libraries, produced different quality output regardless of configuration.

We use tags to inform admins where each slide is being used. Each slide can be tagged by aspect ratio and by the agents that use it. A slide tagged "Sales presentation agent" tells the admin that editing or removing it affects that agent's output.

AI use is opt-in at the slide level. "Make available as AI layout" lets the agent use the slide as a template. Structure is kept, text is regenerated by the AI. The admin decides which slides qualify.

The design starts with a single input. The admin defines the document purpose, audience and blueprint. This came from the chat direction.

Sections sit below as an accordion. Each section contains its setup with instructions, slide sources and content type, AI generated or library based.

Prototypes were tested internally with the PM and discovery engineer, then adjusted and used in customer sessions. Sessions were task driven and focused on creating a proposal blueprint.

The section-creation step is live for all five private-preview customers. Each one has at least one agent configured and in use. Admins are creating agents and generating proposals for a limited group of users inside their organisations.

Templafy uses the product internally too: an RFP agent that matches security questions to answer slides from our library.

I presented the section-first direction to the CPO. The same pattern is now informing other AI features across the platform. The architecture held up beyond the original use case.

What is next in design: integrating user-input questions directly into each section, rather than treating them as a separate, detached feature. When a proposal section depends on industry or target role, the section itself should define the input it needs, not a global form the user fills before generation starts.