Building a Secure AI Assistant for Visual Effects Artists Using Amazon Bedrock

untold_studios · Media & Entertainment · 2025 · source Agentic: yes · promotional bias: med · source-backed · extracted with prompt 0.5.4 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Secure creative-studio AI assistant

Untold Studios needed to give visual effects and animation artists a natural-language way to access internal resources, tools, workflows, and creative-generation capabilities without forcing context switches or compromising strict data-security requirements.

Constraints:

Architecture

Untold Assistant is a Slack-integrated serverless AWS application using Amazon Bedrock with Claude 3.5 Sonnet, Stable Diffusion 3, and Bedrock knowledge-base connectors. API Gateway receives Slack events, a reserved-capacity Lambda acknowledges within Slack's 3-second window, a second Lambda performs longer processing, Bedrock handles NLP and function calling, RAG connectors reach Confluence, Salesforce, and S3-backed asset metadata, DynamoDB stores user mappings, memories, logs, and tool invocations, and CloudWatch plus Slack alerts monitor errors.

Diagram confidence: explicit (topology described by the source).

flowchart LR
  artist[Artist] --> slack[Slack]
  slack[Slack] --> api-gateway[API Gateway]
  api-gateway[API Gateway] --> acknowledgment-lambda[Acknowledgment Lambda]
  acknowledgment-lambda[Acknowledgment Lambda] --> processing-lambda[Processing Lambda]
  processing-lambda[Processing Lambda] --> amazon-bedrock[Amazon Bedrock]
  amazon-bedrock[Amazon Bedrock] --> claude-3-5-sonnet[Claude 3.5 Sonnet]
  amazon-bedrock[Amazon Bedrock] --> stable-diffusion[Stable Diffusion]
  amazon-bedrock[Amazon Bedrock] --> rag-connectors[RAG Connectors]
  rag-connectors[RAG Connectors] --> internal-resources[Internal Resources]
  processing-lambda[Processing Lambda] --> dynamodb[DynamoDB]
  processing-lambda[Processing Lambda] --> cloudwatch[CloudWatch]
Drag to pan · scroll or use +/− to zoom · reconstructed from the source's described component topology

Components

Component Role Interacts with
Artist Visual effects or animation user asking natural-language questions and requesting tasks. Slack
Slack User interface and event source for DMs, mentions, threads, reactions, and file sharing. Artist, API Gateway
API Gateway Slack event endpoint for incoming assistant messages. Slack, Acknowledgment Lambda
Acknowledgment Lambda Reserved-capacity Lambda that responds quickly to Slack and forwards work. API Gateway, Processing Lambda
Processing Lambda Main workflow executor for Bedrock calls, function calls, RAG, memory, and response formatting. Acknowledgment Lambda, Amazon Bedrock, DynamoDB, CloudWatch
Amazon Bedrock Managed model and knowledge-base service for Claude, Stable Diffusion, function calling, embeddings, vector storage, and search. Processing Lambda, Claude 3.5 Sonnet, Stable Diffusion, RAG Connectors
Claude 3.5 Sonnet Natural-language reasoning and function-calling model. Amazon Bedrock
Stable Diffusion Image-generation model available through Bedrock. Amazon Bedrock
RAG Connectors Confluence, Salesforce, and S3 knowledge connectors for internal data access. Amazon Bedrock, Internal Resources
Internal Resources Knowledge bases, internal tools, workflows, and asset-library metadata. RAG Connectors
DynamoDB Persistent storage for user mappings, preferences, logs, and tool invocations. Processing Lambda
CloudWatch Performance and error monitoring with critical-error Slack notifications. Processing Lambda

Data flow

An artist sends a Slack DM or @mention. API Gateway receives the Slack event, the first Lambda quickly acknowledges with a gear emoji and forwards work to the second Lambda, Claude 3.5 Sonnet decides whether to answer directly or call a tool, role-restricted tools access Confluence, Salesforce, S3 asset metadata, image generation, or stored user preferences, and the assistant responds in Slack while logging queries and tool calls to DynamoDB.

3 supporting quotes
“The incoming event from Slack is sent to an endpoint in API Gateway, and Slack expects a response in less than 3 seconds”article, stated
“The first Lambda function, with reserved capacity, quickly acknowledges the event and forwards the request to the second function”article, stated
“Based on this information, the LLM decides if an incoming request can be solved directly or if the best next step to solve the query would be a function call.”article, stated

Why this architecture

Untold used Slack to avoid context switching, Bedrock to keep data inside AWS while gaining Claude, Stable Diffusion, and managed RAG connectors, and a two-Lambda pattern to satisfy Slack's acknowledgment SLA without adding SNS/SQS latency. Role-restricted tools and DynamoDB-backed user mapping keep capabilities aligned with each artist's authority.

3 supporting quotes
“Because our teams already use Slack throughout the day, this eliminates context switching and the need to adopt new software.”article, stated
“By keeping all data within the AWS ecosystem, we’ve eliminated dependencies on third-party AI tools and mitigated associated risks.”article, stated
“The setup handles time-sensitive responses while allowing for thorough request processing. We call the second function directly from the first function without using an event with Amazon Simple Notification Service (Amazon SNS) or a queue with [Amazon Simple Queue”article, stated

Models used: Anthropic Claude 3.5 Sonnet · Stable Diffusion 3 · Amazon Titan Text Embeddings

Scale

Alternatives considered (roads not taken)

Build a custom frontend

Rejected because: Slack already provided the needed UI primitives and reduced context switching.

“For the UI, we use Slack’s built-in features rather than building custom frontends. Slack already provides applications for workstations and phones, message threads for complex queries, emoji reactions for feedback, and file sharing capabilities.”article, stated
“Because our teams already use Slack throughout the day, this eliminates context switching and the need to adopt new software. Every new message is acknowledged by a gear emoji for immediate feedback, which eventually changes to a check mark if the query was successful or an X if an error occurred.”article, stated

Insert SNS or SQS between the Slack acknowledgment and processing Lambda

Rejected because: Untold called the second function directly to keep latency low.

“The setup handles time-sensitive responses while allowing for thorough request processing. We call the second function directly from the first function without using an event with Amazon Simple Notification Service (Amazon SNS) or a queue with [Amazon Simple Queue”article, stated
“the second function directly from the first function without using an event with Amazon Simple Notification Service (Amazon SNS) or a queue with Amazon Simple Queue Service (Amazon SQS) in between to keep the latency as low as possible.”article, stated

Use LangChain-style comprehensive function-calling frameworks

Rejected because: A lightweight custom function-calling approach kept footprint small and focused on the use case.

“Although frameworks like LangChain offer comprehensive solutions for implementing function calling systems, we opted for a lightweight, custom approach”article, stated

Build custom vector store and embedding pipelines

Rejected because: Bedrock connectors handled embeddings, vector storage, and search, reducing development time.

“For example, we export pre-chunked asset metadata from our asset library to Amazon S3, letting Amazon Bedrock handle embeddings, vector storage, and search. This approach significantly decreased development time and complexity, allowing us to focus on improving user experience.”article, stated
“Using function calling and pre-built connectors in Amazon Bedrock eliminated the need for complex vector store integrations and custom embedding pipelines, reducing our development time from months to weeks.”article, stated

Patterns

tool-use-orchestration (agent-architecture)

Claude function calling converts natural-language artist requests into structured tool invocations.

“function calling, which allows us to extend the capabilities of LLMs beyond merely generating text.”article, stated

rag-retrieval (retrieval)

Bedrock connectors provide RAG over Confluence, Salesforce, and S3-backed asset metadata.

“Our RAG setup uses Amazon Bedrock connectors to integrate with Confluence and Salesforce”article, stated

safety-policy-enforcement (security)

Tool access is restricted by mapped user roles and clearance levels.

“Every tool encapsulates a data source and the LLM’s access to tools is restricted by the user and their role.”article, stated

agent-memory (personalization)

The assistant stores user preferences and adds them to future request context.

“we store this piece of information in a database and add it to the context every time the user initiates a request.”article, stated

observability-tracing (operations)

Queries and tool invocations are logged to DynamoDB and errors are monitored through CloudWatch and Slack notifications.

“Every query and tool invocation is logged to DynamoDB, providing a rich dataset”article, stated

Tradeoffs

Use Slack as the assistant interface

Chose Slack built-in features over A custom frontend.

Rationale: Slack already had threads, reactions, file sharing, and daily artist usage, reducing friction and context switching.

“Slack already provides applications for workstations and phones, message threads for complex queries, emoji reactions for feedback, and file sharing capabilities.”article, stated
“this eliminates context switching and the need to adopt new software.”article, stated

Use Bedrock managed connectors

Chose Amazon Bedrock connectors and managed vector services over Custom vector store integrations and embedding pipelines.

Rationale: Managed connectors reduced development time and complexity while keeping data in AWS.

“This approach significantly decreased development time and complexity”article, stated
“reducing our development time from months to weeks.”article, stated

Keep function calling lightweight

Chose Custom single-pass function calling over Comprehensive framework-based function-calling loops.

Rationale: A smaller custom footprint was enough for the use case and kept the system robust.

“we opted for a lightweight, custom approach tailored to our specific needs.”article, stated
“we only implement a single pass function call to keep things simple and robust.”article, stated

Gotchas (what bit them)

Slack event handling has a hard acknowledgment window.

Root cause: Slack fails requests that are not acknowledged in under 3 seconds.

Resolution: Untold uses a two-Lambda path: one immediate acknowledgment function and one unrestricted processing function.

“Slack expects a response in less than 3 seconds, otherwise the request fails.”article, stated
“The first Lambda function, with reserved capacity, quickly acknowledges the event and forwards the request to the second function”article, stated

Natural-language access must still enforce authorization.

Root cause: Different artists have different roles and clearance levels for internal data and tools.

Resolution: Slack user IDs are mapped to internal users and tool access is restricted by role.

“This system tailors the assistant’s capabilities to each user’s role and clearance level”article, stated
“the LLM’s access to tools is restricted by the user and their role.”article, stated

Function-calling loops can add complexity and risk.

Root cause: Agents can call functions repeatedly until success, but Untold wanted simple robust behavior.

Resolution: The implementation uses a single-pass function call.

“Agents use this system in a loop to call functions and process their output until a success criterion is reached.”article, stated
“In our case, we only implement a single pass function call to keep things simple and robust.”article, stated

Evaluation

Untold monitors performance and errors through CloudWatch, logs every query and tool invocation to DynamoDB, uses Slack reactions for immediate feedback, and plans clustering of saved queries to improve the knowledge base.

Metrics: up to 120 queries per day · 10-20% tool-call rate · minutes to seconds time reduction · more than 10 similar questions in a week threshold · CloudWatch performance and error states

3 supporting quotes
“in Lambda to track system performance and error states.”article, stated
“Every query and tool invocation is logged to DynamoDB”article, stated
“When the cluster frequency exceeds our defined threshold (for example, more than 10 similar questions from different users within a week)”article, stated

Outcomes

The system is available around the clock for artists and is built for rapid addition of new function calls such as render job error analysis.

3 supporting quotes
“The Untold Assistant currently handles up to 120 queries per day, with about 10–20% of them calling additional tools”article, stated
“This can cut down the time from minutes to only a few seconds.”article, stated
“reducing our development time from months to weeks.”article, stated