FEATURES
Organize platform capabilities by product family, compare them in clear matrix tables, and keep the structure ready for standalone feature detail pages later.
Blank placeholder
Swap in a feature screenshot or product artwork later.
TOP LEVEL FEATURES
ENTERPRISE FEATURES
The real admin surface centers on agent creation, versioning, import/export, scope controls, and operational configuration inside the enterprise UI.
AUTHENTICATION
The implemented access model centers on agent API keys, signed or encrypted tokens, origin controls, and agent/context resolution.
SDK
The implemented surfaces are a standalone widget script, a JS API, trigger elements, and internal Rails/Stimulus helpers.
WHITE LABEL
The external widget supports multiple themes, title overrides, display modes, and custom theme builds for branded deployments.
AGENT FEATURES
This is where the real PrintSpeak AI surface is strongest: model selection, prompting, facets, tools, actions, routing, charts, and triggers.
REPORTING & QA
PrintSpeak has AI usage reporting, conversation history, previews, and internal test utilities. It does not expose the broad evaluation matrix we previously described.
ENTERPRISE FEATURES
These are the builder and governance features clearly exposed in the PrintSpeak AI agent management screens.
Agent builder workspace
Includes
Dedicated enterprise pages for creating, editing, and organizing AI agents.
Why it matters
The admin flow is centered on `/enterprises/ai_agents`, not a hidden config file or developer-only interface.
Version history
Includes
PaperTrail-backed create, update, and destroy history for agent records.
Why it matters
Editors can inspect prior changes instead of treating each prompt edit as ephemeral.
Import and export
Includes
Base64-backed export/import for agent configs, including prompts, tools, facets, and category settings.
Why it matters
Makes it practical to clone or move agents between enterprises without rebuilding them by hand.
Enterprise and global scope
Includes
Agents can be enterprise-scoped, global, or marked for external use.
Why it matters
This matches the actual `enterprise_id = 0`, external toggle, and scope logic in the model/controller layer.
External-use validation
Includes
Warnings when externally available agents depend on non-external routed assistants.
Why it matters
The builder surfaces configuration issues before an embed is pushed live.
Category assignment
Includes
Prompt categories with single-agent or multi-agent behavior by category.
Why it matters
The category system is part of the real agent model and determines how agents are used in the app.
Bulk model edits
Includes
Enterprise users can update the selected model across multiple agents.
Why it matters
This is more grounded than claiming rollout policies or release orchestration that the code does not show.
Translated names and descriptions
Includes
Agent name and description translation fields are generated and rendered in the UI.
Why it matters
That is a concrete multilingual capability in the admin layer, unlike broader claims about full platform localization.
| Capability | Includes | Why it matters |
|---|---|---|
Agent builder workspace | Dedicated enterprise pages for creating, editing, and organizing AI agents. | The admin flow is centered on `/enterprises/ai_agents`, not a hidden config file or developer-only interface. |
Version history | PaperTrail-backed create, update, and destroy history for agent records. | Editors can inspect prior changes instead of treating each prompt edit as ephemeral. |
Import and export | Base64-backed export/import for agent configs, including prompts, tools, facets, and category settings. | Makes it practical to clone or move agents between enterprises without rebuilding them by hand. |
Enterprise and global scope | Agents can be enterprise-scoped, global, or marked for external use. | This matches the actual `enterprise_id = 0`, external toggle, and scope logic in the model/controller layer. |
External-use validation | Warnings when externally available agents depend on non-external routed assistants. | The builder surfaces configuration issues before an embed is pushed live. |
Category assignment | Prompt categories with single-agent or multi-agent behavior by category. | The category system is part of the real agent model and determines how agents are used in the app. |
Bulk model edits | Enterprise users can update the selected model across multiple agents. | This is more grounded than claiming rollout policies or release orchestration that the code does not show. |
Translated names and descriptions | Agent name and description translation fields are generated and rendered in the UI. | That is a concrete multilingual capability in the admin layer, unlike broader claims about full platform localization. |
AUTHENTICATION
This section reflects the access features actually documented and implemented for embedded PrintSpeak agents.
Agent API keys
Includes
Each integration key has a `client_id`, `client_secret`, `default_agent_ref`, and `agent_mappings`.
Why it matters
This is the real authentication surface for embedded agents, not a generic end-user login matrix.
JWT tokens
Includes
Signed HS256 tokens with the `kid` header set to the public client ID.
Why it matters
Claims become verified agent context and cannot be tampered with client-side.
JWE tokens
Includes
Encrypted tokens using a SHA256-derived key from the client secret.
Why it matters
Sensitive embed context can be hidden from the end user, not merely signed.
Allowed origins
Includes
Per-key origin allowlists with wildcard support.
Why it matters
The system checks widget origin before allowing a token to be used on a site.
Agent reference routing
Includes
The `agent` claim resolves through `agent_mappings` and falls back to `default_agent_ref`.
Why it matters
That is the concrete mechanism for multi-agent external access control.
Internal context injection
Includes
API keys can inject enterprise, tenant, or user lookup context through `context_config`.
Why it matters
The embed surface is more than auth alone; it can attach scoped internal context server-side.
Recognized identity claims
Includes
Claims like `first_name` and `last_name` are explicitly recognized for personalized greetings.
Why it matters
This is narrower and more accurate than claiming broad profile sync or user provisioning.
Legacy public mode
Includes
A non-API-key JWE config-token mode still exists for public agents.
Why it matters
PrintSpeak supports both legacy public embedding and the newer authenticated SDK flow.
| Capability | Includes | Why it matters |
|---|---|---|
Agent API keys | Each integration key has a `client_id`, `client_secret`, `default_agent_ref`, and `agent_mappings`. | This is the real authentication surface for embedded agents, not a generic end-user login matrix. |
JWT tokens | Signed HS256 tokens with the `kid` header set to the public client ID. | Claims become verified agent context and cannot be tampered with client-side. |
JWE tokens | Encrypted tokens using a SHA256-derived key from the client secret. | Sensitive embed context can be hidden from the end user, not merely signed. |
Allowed origins | Per-key origin allowlists with wildcard support. | The system checks widget origin before allowing a token to be used on a site. |
Agent reference routing | The `agent` claim resolves through `agent_mappings` and falls back to `default_agent_ref`. | That is the concrete mechanism for multi-agent external access control. |
Internal context injection | API keys can inject enterprise, tenant, or user lookup context through `context_config`. | The embed surface is more than auth alone; it can attach scoped internal context server-side. |
Recognized identity claims | Claims like `first_name` and `last_name` are explicitly recognized for personalized greetings. | This is narrower and more accurate than claiming broad profile sync or user provisioning. |
Legacy public mode | A non-API-key JWE config-token mode still exists for public agents. | PrintSpeak supports both legacy public embedding and the newer authenticated SDK flow. |
SDK
This is the real embedding stack exposed in PrintSpeak today, without overstating it as a React SDK or headless platform.
Script-tag embed
Includes
A standalone `printspeak-agent.js` widget loaded with `data-domain` and `data-token`.
Why it matters
This is the primary external integration path documented in the SDK guide and usage UI.
Rails helper components
Includes
`ai_agent`, `ai_input`, `ai_submit`, `ai_message`, and related helper methods for internal app surfaces.
Why it matters
Internal product embedding is helper-driven rather than a separate component SDK package.
Stimulus controller integration
Includes
Role-based agent controllers wired to `AgentsChannel` for streaming and action handling.
Why it matters
The frontend runtime is explicitly built around Stimulus plus ActionCable.
Trigger links and buttons
Includes
Elements with `data-psagent-token` can open different agents with different context on click.
Why it matters
This is a real multi-agent embed pattern, not just a single fixed launcher.
Auto-send messages
Includes
Trigger elements can include `data-psagent-message` to open the chat and send a predefined prompt.
Why it matters
Useful for routing pricing, support, or onboarding flows into purpose-built prompts.
Programmatic widget API
Includes
`PSAgent.open`, `close`, `send`, `destroy`, `showToggle`, and `hideToggle`.
Why it matters
The JS API is real and should be described directly instead of implying a broader event SDK.
Multiple widget instances and roles
Includes
The frontend architecture supports multiple agent interfaces and role-specific controller behavior.
Why it matters
This is visible in the controller docs and makes the embed/runtime story more concrete.
Config precedence
Includes
Widget config resolves from script data attributes and can be overridden with `window.PSAgentConfig`.
Why it matters
This is an actual implementation detail that matters for advanced embeds.
| Capability | Includes | Why it matters |
|---|---|---|
Script-tag embed | A standalone `printspeak-agent.js` widget loaded with `data-domain` and `data-token`. | This is the primary external integration path documented in the SDK guide and usage UI. |
Rails helper components | `ai_agent`, `ai_input`, `ai_submit`, `ai_message`, and related helper methods for internal app surfaces. | Internal product embedding is helper-driven rather than a separate component SDK package. |
Stimulus controller integration | Role-based agent controllers wired to `AgentsChannel` for streaming and action handling. | The frontend runtime is explicitly built around Stimulus plus ActionCable. |
Trigger links and buttons | Elements with `data-psagent-token` can open different agents with different context on click. | This is a real multi-agent embed pattern, not just a single fixed launcher. |
Auto-send messages | Trigger elements can include `data-psagent-message` to open the chat and send a predefined prompt. | Useful for routing pricing, support, or onboarding flows into purpose-built prompts. |
Programmatic widget API | `PSAgent.open`, `close`, `send`, `destroy`, `showToggle`, and `hideToggle`. | The JS API is real and should be described directly instead of implying a broader event SDK. |
Multiple widget instances and roles | The frontend architecture supports multiple agent interfaces and role-specific controller behavior. | This is visible in the controller docs and makes the embed/runtime story more concrete. |
Config precedence | Widget config resolves from script data attributes and can be overridden with `window.PSAgentConfig`. | This is an actual implementation detail that matters for advanced embeds. |
WHITE LABEL
The strongest white-label story in PrintSpeak today is around the standalone widget’s visual presentation and deployment options.
Preset themes
Includes
Default, solid-color, gradient, neon-glow, and glass-morphism theme variants.
Why it matters
The codebase ships multiple ready-made branded looks instead of a single hard-coded chat skin.
Header title override
Includes
Widget title text is configurable through `data-title`.
Why it matters
This is a simple but real white-label control exposed directly in the embed code.
Auto-open mode
Includes
The widget can open immediately on load rather than starting as a minimized launcher.
Why it matters
This supports different branded launch experiences depending on the host site.
Hidden-toggle mode
Includes
The floating bubble can be removed entirely so the widget opens only from your own buttons or links.
Why it matters
This allows the host application to own the visible entry point into the experience.
Responsive widget states
Includes
Floating, open, expanded, and mobile-fullscreen widget behaviors.
Why it matters
The widget has multiple presentation states that affect how branded embeds feel across devices.
Custom theme build pipeline
Includes
Teams can add a new SCSS theme and rebuild themed CSS assets into `public/agent_standalone`.
Why it matters
This is the factual extension point for deeper visual customization.
Optional bundled styles
Includes
The external docs expose `data-include-styles` as a configurable option.
Why it matters
That gives integrators some control over how much styling the widget injects by default.
External widget preview
Includes
When external use is enabled, the builder exposes an External Widget tab with theme/title settings.
Why it matters
The white-label experience is not only documented; it is configurable inside the enterprise UI.
| Capability | Includes | Why it matters |
|---|---|---|
Preset themes | Default, solid-color, gradient, neon-glow, and glass-morphism theme variants. | The codebase ships multiple ready-made branded looks instead of a single hard-coded chat skin. |
Header title override | Widget title text is configurable through `data-title`. | This is a simple but real white-label control exposed directly in the embed code. |
Auto-open mode | The widget can open immediately on load rather than starting as a minimized launcher. | This supports different branded launch experiences depending on the host site. |
Hidden-toggle mode | The floating bubble can be removed entirely so the widget opens only from your own buttons or links. | This allows the host application to own the visible entry point into the experience. |
Responsive widget states | Floating, open, expanded, and mobile-fullscreen widget behaviors. | The widget has multiple presentation states that affect how branded embeds feel across devices. |
Custom theme build pipeline | Teams can add a new SCSS theme and rebuild themed CSS assets into `public/agent_standalone`. | This is the factual extension point for deeper visual customization. |
Optional bundled styles | The external docs expose `data-include-styles` as a configurable option. | That gives integrators some control over how much styling the widget injects by default. |
External widget preview | When external use is enabled, the builder exposes an External Widget tab with theme/title settings. | The white-label experience is not only documented; it is configurable inside the enterprise UI. |
AGENT FEATURES
The rows below are grounded in the registered facets, tools, actions, and builder controls found in the PrintSpeak codebase.
Model picker
Includes
A searchable model chooser backed by the `Ai::MODELS` registry and per-model score cards.
Why it matters
PrintSpeak clearly supports multiple LLMs and treats model choice as an editor-facing feature.
Prompt templates and instructions
Includes
Template loading plus a system prompt editor in the agent builder.
Why it matters
The product exposes instruction authoring directly, rather than hiding it as a developer-only concern.
Behavior facet
Includes
Configurable style, creativity, and formality controls.
Why it matters
This is explicitly implemented and should be described using the actual control surface.
Attached resources
Includes
Agents can attach assets, expose snippets to prompts, and enable the resource tool.
Why it matters
This is the concrete document-context feature in PrintSpeak, and it pairs with the embedding service in the codebase.
Web research tools
Includes
Google Custom Search via `web_search` plus page extraction through `visit_url`.
Why it matters
The product genuinely supports live web research rather than static-only prompt grounding.
Business data facets
Includes
Company, tenant, enterprise, user, review, estimate, sales info, and sales metrics context.
Why it matters
These domain-specific facets are a stronger and more factual story than vague 'enterprise context' claims.
Chart rendering
Includes
Inline chart generation using the chart facet and registered business chart sources.
Why it matters
Chart support is directly implemented and scoped to tenant or company context.
Classification facet
Includes
Quality, type, and priority classification against configurable prompt rules.
Why it matters
This is a real structured classifier and feeds directly into user-query trigger logic.
Multi-agent routing
Includes
Ask-facet routing to other agents, with mention and slash-command routing layered on top.
Why it matters
The routing story is real and richer than a single chatbot facade.
@mentions and slash commands
Includes
Hidden mention and command facets route `@agent-name` and `/command` style inputs.
Why it matters
This is implemented behavior, not speculative product positioning.
Actions with undo support
Includes
Company updates, industry updates, saved structured data, note creation, and Freshdesk ticket creation.
Why it matters
Several actions are auto-approved, and some explicitly support undo via stored undo data.
Feedback and response helpers
Includes
Feedback buttons, copy-to-clipboard UI, related follow-up questions, and status indicators.
Why it matters
These response embellishments are actual facets in the renderer pipeline.
Scheduled and query triggers
Includes
Hourly/daily/weekly schedule triggers plus user-query triggers with classification prompts, tenant targeting, and Run Now.
Why it matters
Trigger automation is a real feature family that deserves to be stated precisely.
| Capability | Includes | Why it matters |
|---|---|---|
Model picker | A searchable model chooser backed by the `Ai::MODELS` registry and per-model score cards. | PrintSpeak clearly supports multiple LLMs and treats model choice as an editor-facing feature. |
Prompt templates and instructions | Template loading plus a system prompt editor in the agent builder. | The product exposes instruction authoring directly, rather than hiding it as a developer-only concern. |
Behavior facet | Configurable style, creativity, and formality controls. | This is explicitly implemented and should be described using the actual control surface. |
Attached resources | Agents can attach assets, expose snippets to prompts, and enable the resource tool. | This is the concrete document-context feature in PrintSpeak, and it pairs with the embedding service in the codebase. |
Web research tools | Google Custom Search via `web_search` plus page extraction through `visit_url`. | The product genuinely supports live web research rather than static-only prompt grounding. |
Business data facets | Company, tenant, enterprise, user, review, estimate, sales info, and sales metrics context. | These domain-specific facets are a stronger and more factual story than vague 'enterprise context' claims. |
Chart rendering | Inline chart generation using the chart facet and registered business chart sources. | Chart support is directly implemented and scoped to tenant or company context. |
Classification facet | Quality, type, and priority classification against configurable prompt rules. | This is a real structured classifier and feeds directly into user-query trigger logic. |
Multi-agent routing | Ask-facet routing to other agents, with mention and slash-command routing layered on top. | The routing story is real and richer than a single chatbot facade. |
@mentions and slash commands | Hidden mention and command facets route `@agent-name` and `/command` style inputs. | This is implemented behavior, not speculative product positioning. |
Actions with undo support | Company updates, industry updates, saved structured data, note creation, and Freshdesk ticket creation. | Several actions are auto-approved, and some explicitly support undo via stored undo data. |
Feedback and response helpers | Feedback buttons, copy-to-clipboard UI, related follow-up questions, and status indicators. | These response embellishments are actual facets in the renderer pipeline. |
Scheduled and query triggers | Hourly/daily/weekly schedule triggers plus user-query triggers with classification prompts, tenant targeting, and Run Now. | Trigger automation is a real feature family that deserves to be stated precisely. |
REPORTING & QA
This section is intentionally narrower after factchecking. It reflects the real reporting and preview surfaces available today.
AI usage summary
Includes
Pie-chart and area-chart views summarizing usage across agents and months.
Why it matters
There is a real reporting dashboard for adoption and traffic, which is stronger than inventing a test suite.
Usage by user
Includes
Date-range filtered user breakdowns with CSV export.
Why it matters
This is a concrete operational report exposed in enterprise reporting.
Usage by tenant
Includes
Date-range filtered tenant breakdowns with CSV export.
Why it matters
This gives rollout visibility by location or business unit without overstating QA coverage.
Conversation history
Includes
A filterable AI conversation list by agent, model, and tenant.
Why it matters
This is the real operational audit/review surface for AI usage.
Conversation transcript view
Includes
Per-conversation transcript display with message counts, metadata, and timestamps.
Why it matters
Reviewers can inspect what actually happened in production conversations.
Agent preview
Includes
The agent builder includes a live preview entry point for the current configuration.
Why it matters
Editors can manually validate changes before treating the agent as ready.
Facet previews
Includes
Builder modals preview how individual facets inject or render context.
Why it matters
This supports configuration QA even though it is not a formal regression runner.
Instructions preview
Includes
A dedicated preview for the final instruction set sent to the model.
Why it matters
Prompt QA is supported at the builder layer, which is more accurate than claiming answer baselines.
Widget configuration preview
Includes
External widget configuration pages show themes, titles, and validation warnings.
Why it matters
This supports embed QA for external agents before sharing code with customers.
Internal SDK test harnesses
Includes
The repo includes an SDK test page and headless test scripts for widget verification.
Why it matters
These are real internal QA utilities, but they should not be presented as a polished customer-facing evaluation suite.
| Capability | Includes | Why it matters |
|---|---|---|
AI usage summary | Pie-chart and area-chart views summarizing usage across agents and months. | There is a real reporting dashboard for adoption and traffic, which is stronger than inventing a test suite. |
Usage by user | Date-range filtered user breakdowns with CSV export. | This is a concrete operational report exposed in enterprise reporting. |
Usage by tenant | Date-range filtered tenant breakdowns with CSV export. | This gives rollout visibility by location or business unit without overstating QA coverage. |
Conversation history | A filterable AI conversation list by agent, model, and tenant. | This is the real operational audit/review surface for AI usage. |
Conversation transcript view | Per-conversation transcript display with message counts, metadata, and timestamps. | Reviewers can inspect what actually happened in production conversations. |
Agent preview | The agent builder includes a live preview entry point for the current configuration. | Editors can manually validate changes before treating the agent as ready. |
Facet previews | Builder modals preview how individual facets inject or render context. | This supports configuration QA even though it is not a formal regression runner. |
Instructions preview | A dedicated preview for the final instruction set sent to the model. | Prompt QA is supported at the builder layer, which is more accurate than claiming answer baselines. |
Widget configuration preview | External widget configuration pages show themes, titles, and validation warnings. | This supports embed QA for external agents before sharing code with customers. |
Internal SDK test harnesses | The repo includes an SDK test page and headless test scripts for widget verification. | These are real internal QA utilities, but they should not be presented as a polished customer-facing evaluation suite. |