nOps rebuilds Clara around a managed FinOps agent stack
nOps says it rebuilt its Clara FinOps AI agent on Amazon Bedrock AgentCore, replacing a self-managed stack that combined Amazon EKS, LangChain, LangGraph and API-based tool wrappers. The company reports that the move reduced time-to-production by 75%, from 10-12 months to 4 months, while improving measured response quality and lowering tool failure rates. The case is a vendor-published technical account, so the figures should be read as company-reported results rather than an independent benchmark. For cloud finance teams, the useful signal is architectural: nOps shifted the agent closer to governed analytics definitions rather than treating product APIs as the main source of analytical context.Why nOps rebuilt Clara
nOps says Clara’s first version was built quickly, but its API-centric infrastructure became harder to scale as analytics workflows grew more complex. The original setup used Kubernetes, Amazon Bedrock model invocation, LangChain and LangGraph orchestration, plus tool wrappers around web APIs.According to the AWS Machine Learning Blog post, this design created latency and consistency problems because large API-shaped context had to be passed into model interactions. nOps also describes operational overhead from multiple orchestration and observability layers, which pulled engineering effort toward maintenance rather than product work.
That matters because FinOps agents are not simple chatbots. A user asking about commitment utilization, discounted cost or account-level spend needs answers that match dashboard definitions and internal business rules. If the agent and dashboard calculate from different paths, the result can be slower iteration and inconsistent decision support.
AgentCore becomes the main runtime
The rebuilt Clara uses Amazon Bedrock AgentCore for agent runtime and orchestration, with the runtime deployed as a Docker container and infrastructure defined in an AWS CDK stack. nOps says the architecture uses one Strands-based agent rather than a multi-agent router, giving it direct tool access for canvas operations, query execution, datasource discovery and workflow orchestration.The single-agent design is presented as a way to reduce routing overhead and make tool dispatch more deterministic. Clara’s conversational interface runs through a Vercel-hosted Next.js application, with requests flowing through a Backend for Frontend that invokes AgentCore and streams responses back to the user.
Streaming is a central part of the reported design. The post describes a custom merge layer between the Strands async stream and Server-Sent Events output, combining heartbeats, readable text buffering and real-time canvas update events. The practical implication is that long analytics tasks can keep the interface responsive instead of forcing users to wait for a single completed response.
Memory and tenant controls are built into the flow
nOps says Clara uses AgentCore memory across three strategies: semantic facts, user preferences and canvas summaries. In the described implementation, preferences can guide layout choices, default aggregations and chart types, while semantic facts capture organizational context such as account structures and cost allocation conventions.The post also says sessions are scoped by canvas rather than by an ephemeral browser session. That lets a user return to an analytical thread after a refresh or reconnection without re-explaining the context, which is especially relevant when a chat response becomes a persistent dashboard artifact.
For isolation, the architecture places Amazon Bedrock Guardrails as a pre-check on raw user prompts before the agent is invoked. nOps also describes a tenant policy layer that sanitizes outbound stream chunks and widget events, including redaction of internal identifiers before content reaches the front end. These controls do not prove security effectiveness by themselves, but they show where the company says tenant and prompt-attack checks are inserted.
Databricks Metric Views replace API-shaped analytics
The biggest analytical change is that Clara no longer relies on generic product APIs for core analytical context. Instead, nOps says it uses curated tools to run SQL against Databricks SQL Warehouse backed by Databricks Lakehouse Metric Views, creating a governed semantic layer for measures and dimensions.The source gives a concrete example: a user asks to see true AWS cost for the last 30 days by account. In a raw SQL or API-shaped approach, the tool would need to recalculate business logic across credits, refunds, commitments and discounts before grouping by account. With a Metric View, the tool can query a predefined measure such as true_customer_cost with account_name and a time range.
This is the technical center of the case study. If chat answers and dashboards use the same governed metric definitions, the agent is less dependent on reconstructing business logic inside prompts or tool wrappers. nOps also uses Databricks Lakebase, described as serverless PostgreSQL, to store product objects, sessions, canvases, widgets and query or chart specifications.
Reported delivery and quality gains
nOps reports a 75% reduction in time-to-production after replacing the self-managed Amazon EKS stack with the managed AgentCore-based approach, moving from 10-12 months to 4 months. The post also says 4-6 production-ready agents now serve analytics across a shared runtime.Quality metrics are also self-reported. nOps gives an 81.7% correctness score, described as up 145% over the previous period and compared with approximately 65% in v1, along with a 79.4% helpfulness score, described as up 138% over the previous period. Tool failure rate reportedly fell from 7.49% to 0.92% after adopting AgentCore with a new tool-calling method.
The company also says manual analysis time for Customer Success Managers and Solutions Architects fell by 75%, from an estimated 2 hours to 30 minutes. Because these figures come from a vendor case study, they should be treated as reported operating results for nOps rather than general performance claims for all FinOps agent deployments.
Conclusion
The nOps case shows a common direction for enterprise AI agents: fewer custom orchestration layers, more managed runtime services and a stronger connection to governed analytics semantics. In this account, AgentCore handles runtime and orchestration, Databricks Metric Views define analytics meaning, Lakebase stores durable state and AWS messaging services support long-running workflows.The most relevant takeaway is not the headline percentage alone. It is the architectural choice to make the agent operate over durable product state and shared metric definitions, instead of relying mainly on large context windows and API-shaped responses. For FinOps teams evaluating similar systems, the hard questions remain measurement quality, tenant isolation, metric governance and whether internal benchmarks hold up outside the vendor’s own environment.
Sources
Editorial Team - CoinBotLab
