Octora: connecting AI agents to the work inside a CRM.
CloudHero built Otto, the AI assistant in Octora, to turn CRM records, conversations and documents into source-linked answers and reviewable actions. Amazon Bedrock provides the model interface; the application controls access, tools and execution.
An opportunity’s next step can depend on a meeting transcript, a commitment in an email, an attached document and the current CRM record. An assistant needs to bring those sources together while respecting the requesting user’s access.
CloudHero develops Octora for AWS partner work. We built Otto around that context: an assistant that can explain an opportunity, identify supporting evidence and prepare the next action for a person to review.
WORKFLOW ARCHITECTURE
From a question to an approved change.
01
Retrieve
Read records and source material the user can access.
02
Reason
Use Bedrock models and bounded application tools.
03
Review
Present sources and an editable action proposal.
04
Validate
Recheck permissions and record state before execution.
AMAZON BEDROCK
A Bedrock integration built for tool use.
The application calls Amazon Bedrock’s Converse API through a shared LLM layer. It supplies conversation context and JSON-schema tool definitions, then handles the model’s tool requests in an application-managed loop. This lets Otto search, read and prepare work through a defined set of capabilities.
Each turn has limits on model calls, tool calls, output tokens and elapsed time. The provider layer records token usage, applies request deadlines and handles selected model-parameter incompatibilities with bounded retries. A dedicated Redis/RQ queue runs Otto turns outside the web request.
The model interface also supports another provider. Keeping this boundary separate from CRM logic lets the application retain its access checks and action workflow when a model configuration changes. Tool execution, retrieval and approvals remain under the application’s control.
WHAT CLOUDHERO BUILT
The engineering around the model.
Retrieval that follows permissions
Structured and full-text retrieval cover CRM records, email, extracted attachment text, transcripts and notes. Readers and search tools apply user and team access rules. Tool responses have bounded sizes so a broad search cannot fill the entire context.
Answers with inspectable evidence
Otto associates citations with retrieved evidence. The answer composer checks source references against that evidence, so a reviewer can follow an answer back to the relevant record. Structured and full-text search supply the context for this workflow.
Proposals before writes
Otto can propose a contact, task, note, record update or email draft. Before execution, the server checks ownership, current source access, input validity and conflicting record changes. Approving an email action saves a draft for review; it does not send the email.
Recovery as part of the workflow
Turn attempts have their own identity. Failed or cancelled turns void staged actions, and proposals carry revisions to detect stale edits. The UI can distinguish prepared work from a change that actually completed.
Shared foundations for several focused agents.
Beyond Otto, the implementation includes qualification, deal intelligence, customer health, AWS coordination, onboarding, voice-note processing and daily digest modules. Their common foundation is the same: scoped business context, configured model access and application-owned execution. An MCP interface also exposes authorised CRM capabilities to external clients with explicit read or read-write scopes. The reviewed runtime separates the Flask/Gunicorn API and Redis/RQ workers, backed by PostgreSQL and packaged as Docker Compose services.
What the implementation makes possible.
A user can ask what is blocking an opportunity, inspect the supporting conversation and review a proposed follow-up without manually assembling context from each source. The engineering contribution is the complete path from retrieval to a checked action: model integration, source handling, permissions, background execution and review.
The same design questions arise in sales operations, account management and internal assistants: what may the model read, what can it propose, and what must the server verify before a change is committed?
RELATED ENGINEERING
Infrastructure and operations on Amazon EKS.
Our separate Waydev customer case study shows the infrastructure side of application modernization: migration to Amazon EKS. Explore that project and the Kubernetes services that support deployment, scaling and ongoing operations.
Essential cookies keep this site working. With your permission, optional cookies help us understand visits and improve the site. You can change your choice at any time.
Needed for site features and to remember your cookie choice.
Allow optional settings to be remembered.
Allow Google Analytics to measure visits and use of the site.
Allow optional advertising and third-party tracking when present.