Bynder, a digital asset management platform serving retail and CPG customers, faced significant operational bottlenecks as users had to manually tag and categorize all uploaded content for searchability. To address this, Bynder built AI search capabilities and four types of configurable AI agents using AWS services including Bedrock, Rekognition, Transcribe, and OpenSearch. The solution enabled natural language search, similarity search, automated content enrichment, brand compliance checking, and governance automation. Results included one major pet food retailer saving almost 4,000 hours of manual tagging work, and a leading tea brand reducing migration time from months to weeks while improving metadata quality.
Bynder provides an enterprise digital asset management (DAM) system that serves as the system of record for digital content across retail and consumer packaged goods (CPG) organizations. The platform helps customers manage images, videos, documents, and other digital assets at scale while maintaining governance, accelerating content operations, and optimizing content delivery across channels. Prior to implementing AI capabilities, Bynder relied solely on lexical search powered by Solr, which created a significant bottleneck requiring customers to manually tag every uploaded asset with metadata properties to enable searchability and organization.
Recognizing the opportunity to leverage modern AI technologies, Bynder developed a comprehensive suite of AI-powered features built on AWS infrastructure, including advanced search capabilities and configurable AI agents. The implementation demonstrates mature LLMOps practices across multiple domains including computer vision, natural language processing, and agentic workflows, all running in production serving enterprise customers.
Bynder operates on a microservices architecture deployed on AWS. The core workflow begins when users upload assets through the browser, API, or integrations, with files stored in Amazon S3 with region optimization based on user location. Metadata persists in Amazon Aurora MySQL databases, and the system follows an event-driven architecture where asset uploads trigger events consumed by various AI processing pipelines.
The event-driven design enables loose coupling between services and allows multiple AI processing domains to operate independently and asynchronously. This architectural pattern supports scalability and resilience, as each domain can process assets at its own pace without blocking the core upload workflow or other processing pipelines.
The similarity search feature addresses a common use case where marketing teams need to find visually similar assets for campaigns. When users click “show similar” on an image, the system retrieves semantically related content from their asset library. The technical implementation involves generating embeddings for uploaded images by calling AWS Bedrock models. Different models are employed depending on the specific customer tenant, suggesting Bynder has implemented a flexible model selection strategy that may account for varying customer requirements, performance characteristics, or cost considerations.
After generating embeddings through Bedrock, the system fires an event containing the embedding vectors. A search indexer service, part of a separate domain, consumes this event and stores the embeddings in OpenSearch, associated with the tenant’s index to maintain data isolation. When users perform similarity searches through the UI, the system executes K-nearest neighbors (KNN) searches against the OpenSearch index to retrieve visually similar images.
The reverse image search capability extends this pipeline by allowing users to upload an external image or provide a URL. The system generates embeddings for this query image using the same Bedrock model with matching dimensions, then executes a KNN search against the tenant’s indexed images to find the most similar assets within their library. This dual approach to similarity search demonstrates thoughtful feature design that accommodates both internal asset discovery and external image matching workflows.
Bynder implemented automated transcription for video and audio assets using Amazon Transcribe. This feature serves multiple purposes: enabling users to view and edit subtitles, searching assets based on spoken content, downloading transcriptions, and accessing transcripts via API for integration scenarios. The implementation handles the asynchronous nature of transcription processing, as large videos may take significant time to process.
The architecture uses Amazon EventBridge to manage the asynchronous workflow. After asset upload, the transcript domain initiates a call to Amazon Transcribe. Rather than blocking while waiting for completion, the system hooks into EventBridge events that Transcribe emits upon completion, consuming these through an SQS queue. Once the transcription is ready, the service persists it in a database associated with the asset, making it available for user editing.
An important production consideration is support for custom vocabularies, allowing customers to configure automatic substitutions for domain-specific terminology, personal names, or company names that might be commonly misrecognized. After persisting the transcript, the system fires an event consumed by the search indexer, which stores the transcribed text in OpenSearch, enabling full-text search across video and audio content. This demonstrates attention to enterprise requirements where accuracy with specialized terminology can significantly impact usability.
The face recognition feature automatically groups images containing the same individuals, which users can then name, rename, or exclude from the system. The implementation leverages AWS Rekognition with multiple API calls. The face recognition domain processor uses Rekognition’s detect faces API and search by face functionality to query against the tenant’s existing face collection, determining whether detected individuals appear in previously processed images.
Detected face data persists in an Amazon Aurora PostgreSQL database, maintaining mappings to assets for use in editing, deletion, and other operations. The system fires events to update the OpenSearch index with named individuals, enabling users to filter or search assets by people’s names. The choice of PostgreSQL for this domain suggests structured relational data requirements, contrasting with the MySQL database used for other metadata, indicating Bynder employs database specialization based on use case requirements.
Beyond search capabilities, Bynder developed a configurable AI agent framework offering four agent types: brand compliance, transformation, governance, and enrichment agents. While these pre-configured agents address common use cases, the platform allows customers to customize prompts and configure agents for their specific business needs, demonstrating a flexible LLMOps approach that balances out-of-the-box functionality with customization.
The agent system includes an agent configuration service backed by Amazon Aurora that stores user-defined configurations. Users configure two types of prompts: global instructions that apply to all agents and contain brand-specific or industry-specific terminology, and agent-specific prompts that define the particular task to execute. This two-tier prompt structure enables customers to establish consistent context while maintaining task flexibility.
Agents can be triggered manually from the asset bank interface or automatically through configured automations based on events like asset publication or field changes. The orchestrator component manages agent execution, receiving triggers either directly from user actions or through SQS for automated workflows. When triggered, the orchestrator retrieves the relevant agent configuration and publishes execution commands to Kafka for each agent that needs to run.
The choice of Kafka for internal agent communication suggests Bynder requires reliable, ordered message delivery with the ability to replay events if necessary. This event-driven orchestration pattern enables scaling agent processing independently from the core application and provides flexibility to add new agent types without modifying the orchestrator.
The enrichment agent exemplifies the general agent execution pattern. Upon receiving an execute command from Kafka containing the configured prompt, the agent begins reasoning about required resources. Typically, the first step involves retrieving the target asset file from S3. Depending on the prompt requirements, the agent may collect additional metadata from the Aurora database to provide context for the LLM.
With the prompt, file, and contextual data assembled, the agent performs inference through AWS Bedrock. Bynder maintains access to multiple models and selects the most appropriate model for each specific use case, suggesting a mature approach to model selection that considers factors like capability requirements, latency, cost, and quality. The implementation also leverages Bedrock Guardrails to prevent generation of inappropriate content and protect against data leakage, demonstrating production-grade safety considerations.
A common use case for enrichment agents is automated alt text generation, where customers configure prompts instructing the agent to analyze images and generate descriptive alt text. This automation eliminates tedious manual work while ensuring accessibility compliance. The flexibility to define custom meta properties and automate their population through agent-generated content represents a significant value proposition for enterprise DAM users managing thousands or millions of assets.
The brand compliance agent allows customers to define brand rules, regulatory requirements, or legal standards against which assets are automatically checked. The agent can verify elements like logo placement, font usage, and other brand guideline adherence, automatically flagging non-compliant assets. This addresses a critical enterprise need for maintaining brand consistency at scale, particularly for organizations with distributed teams or complex approval workflows.
The transformation agent targets the common pain point where creative teams work with external agencies to produce marketing materials, then require changes that necessitate going back to the agency, introducing delays of weeks before assets are market-ready. By enabling certain transformations directly within the DAM system, such as background removal or other repetitive tasks, the agent reduces dependency on external resources and accelerates time to market.
The governance agent addresses content lifecycle management, particularly scenarios like rebranding initiatives or campaign-specific asset restrictions where organizations need to control where assets appear. The agent can scan the web for asset usage, identifying where controlled assets are being used so teams can ensure deprecated assets are removed from inappropriate channels or websites. This capability supports compliance requirements and brand protection objectives.
A critical production design decision is Bynder’s implementation of human-in-the-loop approval for agent suggestions. Rather than having agents directly modify assets, which could introduce errors or unwanted changes at scale, agents publish their suggestions to Kafka. An approval service consumes these events and persists suggestions to a PostgreSQL database. Users review agent suggestions through the UI, where they can discard inappropriate recommendations and approve valuable ones. Only upon user approval does the system make the actual modification request to the asset service.
This workflow demonstrates mature thinking about production AI systems where automation augments rather than replaces human judgment. For enterprise DAM use cases where incorrect metadata or transformations could have significant business impact, requiring human review provides an important safety mechanism while still capturing much of the efficiency benefit by reducing the cognitive load of generating suggestions.
Several aspects of Bynder’s implementation indicate mature LLMOps practices. The event-driven architecture enables resilient, scalable processing where failures in one domain don’t cascade to others. The use of asynchronous processing through EventBridge and SQS accommodates variable processing times for different AI workloads without blocking user interactions.
The multi-tenant architecture with tenant-specific OpenSearch indexes demonstrates attention to data isolation and security requirements for enterprise SaaS applications. The ability to select different Bedrock models per customer or use case suggests sophisticated model management capabilities and likely involves tracking model performance, costs, and customer preferences.
The implementation of Bedrock Guardrails shows awareness of safety and compliance requirements for production LLM applications. Combined with the human-in-the-loop pattern, this indicates a defense-in-depth approach to ensuring AI outputs meet quality and safety standards.
The two-tier prompt configuration system with global and agent-specific prompts provides a practical solution to prompt management at scale. Global instructions establish consistent context and terminology across all agents while agent prompts remain focused on specific tasks, likely improving both prompt maintainability and output quality.
Bynder provides specific customer outcomes demonstrating tangible business value. A major online pet food retailer reported saving almost 4,000 hours by eliminating manual tagging and categorization work, representing substantial cost savings and productivity improvements. A leading tea brand reduced migration time from months to weeks while simultaneously improving metadata quality, indicating the AI features both accelerate workflows and enhance data quality compared to manual processes.
These results, while presented as customer feedback, suggest the AI features deliver measurable operational improvements. However, as with any vendor-provided case study, it’s worth noting that these represent positive outcomes from successful customers rather than guaranteed results across all implementations.
While Bynder’s architecture demonstrates solid LLMOps practices, several aspects warrant balanced consideration. The reliance on AWS-specific services like Bedrock, Rekognition, and Transcribe creates vendor lock-in, though this is offset by AWS’s broad model availability and enterprise-grade reliability. The presentation doesn’t detail model evaluation processes, versioning strategies, or monitoring approaches for detecting model performance degradation over time.
The human-in-the-loop pattern, while valuable for safety, could become a bottleneck as agent usage scales. Organizations with millions of assets may find reviewing all agent suggestions impractical, potentially necessitating different approval workflows for high-confidence suggestions versus those requiring review.
The configuration flexibility allowing customers to write their own prompts creates potential for poorly designed prompts that produce low-quality results. While this empowers advanced users, it may require significant prompt engineering expertise to achieve optimal results, potentially limiting value for less sophisticated users.
The case study also doesn’t address important production concerns like cost management for AI services, latency SLAs for search and agent operations, or strategies for handling model failures or degraded performance scenarios. Multi-model support is mentioned but the criteria for model selection and the process for evaluating new models as they become available aren’t detailed.
Despite these considerations, Bynder’s implementation represents a substantial production deployment of LLM and AI technologies addressing real enterprise pain points in digital asset management. The architectural patterns demonstrated, particularly the event-driven design and human-in-the-loop workflows, offer valuable lessons for organizations building similar production AI systems.
Snorkel developed a specialized benchmark dataset for evaluating AI agents in insurance underwriting, leveraging their expert network of Chartered Property and Casualty Underwriters (CPCUs). The benchmark simulates an AI copilot that assists junior underwriters by reasoning over proprietary knowledge, using multiple tools including databases and underwriting guidelines, and engaging in multi-turn conversations. The evaluation revealed significant performance variations across frontier models (single digits to ~80% accuracy), with notable error modes including tool use failures (36% of conversations) and hallucinations from pretrained domain knowledge, particularly from OpenAI models which hallucinated non-existent insurance products 15-45% of the time.
Notion AI, serving over 100 million users with multiple AI features including meeting notes, enterprise search, and deep research tools, demonstrates how rigorous evaluation and observability practices are essential for scaling AI product development. The company uses Brain Trust as their evaluation platform to manage the complexity of supporting multilingual workspaces, rapid model switching, and maintaining product polish while building at the speed of AI industry innovation. Their approach emphasizes that 90% of AI development time should be spent on evaluation and observability rather than prompting, with specialized data specialists creating targeted datasets and custom LLM-as-a-judge scoring functions to ensure consistent quality across their diverse AI product suite.
Notion, a knowledge work platform serving enterprise customers, spent multiple years (2022-2026) iterating through four to five complete rebuilds of their agent infrastructure before shipping Custom Agents to production. The core problem was enabling users to automate complex workflows across their workspaces while maintaining enterprise-grade reliability, security, and cost efficiency. Their solution involved building a sophisticated agent harness with progressive tool disclosure, SQL-like database abstractions, markdown-based interfaces optimized for LLM consumption, and a comprehensive evaluation framework. The result was a production system handling over 100 tools, serving majority-agent traffic for search, and enabling workflows like automated bug triaging, email processing, and meeting notes capture that fundamentally changed how their company and customers operate.
