nOps Transferiu Clara para amazon aws, Reduzindo em 75% o Prazo do Seu Agente FinOps

A nOps transferiu seu agente FinOps Clara para o amazon aws e afirma que a reconstrução reduziu em 75% o prazo até a produção, de 10–12 meses para quatro meses. A empresa substituiu uma arquitetura autogerenciada no Amazon EKS, construída em torno de LangChain e LangGraph, pelo Amazon Bedrock AgentCore.

A mudança importa porque a nOps não abandonou a lógica de seu agente, os dados na nuvem ou sua camada de análises governadas. Ela mudou a base operacional que os sustenta. O resultado desafia uma suposição comum: a de que as equipes precisam controlar a maior parte da infraestrutura de agentes para manter flexibilidade e controle.

A disputa real é entre infraestrutura gerenciada para agentes e uma pilha Kubernetes operada internamente. A nOps apresenta Clara como evidência de que terceirizar as operações de runtime pode melhorar a velocidade de entrega e a qualidade das respostas. Contudo, os resultados publicados continuam sendo um estudo de caso de cliente, e não uma avaliação independente entre provedores ou cargas de trabalho.

nOps Reconstruiu o Runtime, Não o Produto FinOps

A mudança importante foi arquitetural: a nOps transferiu as operações de produção para o AgentCore, preservando o papel de Clara e sua base de análises governadas.

Clara é um agente de IA dentro da plataforma de otimização em nuvem da nOps. Ele permite que usuários investiguem gastos com AWS, compromissos, utilização e oportunidades de otimização por meio de uma interface conversacional. Uma solicitação pode envolver diversas etapas analíticas, em vez de uma única consulta a banco de dados.

Por exemplo, um usuário pode perguntar por que os gastos com computação aumentaram, quais recursos causaram a mudança e se os compromissos existentes ainda cobrem a carga de trabalho. Clara precisa interpretar a pergunta, selecionar as ferramentas certas, consultar dados governados e elaborar uma resposta que preserve o contexto de negócio.

O sistema anterior era executado no Amazon Elastic Kubernetes Service, ou Amazon EKS, o serviço Kubernetes gerenciado da AWS. A nOps usava LangChain e LangGraph para os fluxos de trabalho do agente, enquanto operava por conta própria a pilha de produção ao redor deles.

Essa abordagem deu à equipe controle sobre implantação e orquestração. Também tornou a nOps responsável por escalabilidade, tratamento de sessões, autenticação, monitoramento, recuperação de falhas e outras questões de produção.

Segundo o estudo de caso da nOps, a empresa esperava que seu caminho original até a produção exigisse 10–12 meses. A implementação com AgentCore chegou a esse ponto em quatro meses, o que a nOps e a AWS caracterizam como uma redução de 75%.

A comparação não significa que o agente subjacente foi criado do zero em quatro meses. A nOps já tinha conhecimento do produto, fluxos de trabalho, infraestrutura de dados e experiência com a implementação anterior de Clara. A aceleração relatada diz respeito à rota revisada para um sistema de produção.

Essa distinção é essencial. Um runtime gerenciado não pode fornecer a expertise FinOps de uma empresa nem definir métricas de nuvem confiáveis. Ele pode eliminar trabalho de infraestrutura que compete com essas tarefas.

A nOps também manteve Databricks Lakehouse Metric Views como sua camada de análises governadas. Uma Metric View é uma definição reutilizável de métrica de negócio, governada pelo Unity Catalog, que ajuda aplicações a usar cálculos consistentes.

Assim, Clara não recebeu permissão para improvisar definições financeiras. O agente podia interpretar perguntas e coordenar ferramentas, enquanto definições de métricas estabelecidas continuavam a governar os resultados analíticos.

Essa separação cria a tensão central do artigo. A nOps trocou a propriedade direta de uma parcela maior da infraestrutura de runtime por componentes operacionais gerenciados, mas manteve o controle da camada de domínio, onde erros trazem consequências financeiras.

A migração também mostra por que “construir versus comprar” é uma descrição incompleta. A nOps ainda desenvolve Clara, mantém sua lógica FinOps e governa seus dados. Agora, ela compra uma parcela maior do ambiente de execução como serviço da AWS.

Por Que amazon aws Está Pressionando Pilhas de Agentes Autogerenciadas

O AgentCore desloca o peso da diferenciação da infraestrutura para as decisões, ferramentas, dados e resultados mensuráveis do agente.

Um agente de protótipo pode ser executado no laptop de um desenvolvedor com um modelo, um prompt e várias funções. Um serviço de produção precisa lidar com usuários simultâneos, tarefas de longa duração, credenciais, isolamento, telemetria e comportamento imprevisível dos modelos.

Esses requisitos explicam por que uma implantação Kubernetes pode se expandir muito além do fluxo de trabalho original do agente. As equipes precisam empacotar serviços, configurar escalabilidade, gerenciar redes, proteger segredos, coletar rastros e diagnosticar falhas em diversos componentes.

O Amazon Bedrock AgentCore reúne várias dessas responsabilidades em serviços gerenciados. Sua visão geral do AgentCore descreve Runtime, Memory, Gateway, Identity, Browser, Code Interpreter e Observability como recursos modulares.

O AgentCore Runtime fornece um ambiente serverless para código e ferramentas de agentes. A AWS afirma que ele oferece suporte a frameworks de código aberto, incluindo LangGraph e LangChain, além de modelos dentro ou fora do Amazon Bedrock.

Essa compatibilidade é relevante para a migração da nOps. A transferência para um runtime gerenciado da AWS não exigiu necessariamente descartar os conceitos de framework usados no sistema anterior de Clara.

O AgentCore Gateway transforma APIs, funções Lambda e outros serviços em ferramentas governadas que os agentes podem chamar. Identity lida com autenticação e credenciais, enquanto Observability expõe logs, rastros e métricas por meio dos serviços de monitoramento da AWS.

Isso altera a pressão sobre equipes que mantêm uma plataforma de agentes por conta própria. Cada mês gasto aprimorando componentes genéricos de runtime é um mês não dedicado a testar respostas, ampliar a cobertura de domínio ou reduzir alucinações.

A pressão é mais forte para empresas cuja vantagem competitiva não vem da operação de Kubernetes. A nOps vende inteligência e otimização de nuvem, não um runtime de agentes de propósito geral.

Seus desenvolvedores ainda precisam de habilidades de infraestrutura porque Clara se conecta a dados sensíveis de nuvem e finanças. No entanto, há menos motivos para controlar cada componente indiferenciado se um serviço gerenciado atende a seus requisitos de segurança e confiabilidade.

A entrega relatada em quatro meses também eleva as expectativas para equipes internas de plataforma. Líderes de negócio agora podem comparar um programa de infraestrutura proposto de 10 meses com um estudo de caso de cliente que afirma chegar à produção em menos da metade desse tempo.

Essa comparação nem sempre será justa. Sistemas existentes têm regras de conformidade, limites de rede, cargas de trabalho e custos de migração diferentes. Ainda assim, serviços gerenciados criam uma alternativa visível que as equipes de plataforma precisam enfrentar.

A AWS também enfrenta pressão. Ao comercializar o AgentCore como um caminho mais rápido para a produção, os clientes esperarão mais do que uma implantação conveniente. Eles esperarão escalabilidade previsível, telemetria útil, integrações seguras e comportamento estável durante sessões complexas.

O serviço também precisa permanecer flexível o suficiente para que desenvolvedores preservem escolhas de framework e modelo. Uma plataforma gerenciada perde boa parte de seu apelo se a conveniência se transformar em confinamento arquitetural.

A documentação da AWS afirma que Runtime pode hospedar código de agente personalizado e trabalhar com diversos provedores de modelos. Isso reduz a dependência imediata de frameworks, mas a dependência operacional ainda pode se desenvolver em torno de identidade, gateways, telemetria e controles de implantação.

O caso da nOps, portanto, pressiona os dois lados. Plataformas autogerenciadas precisam justificar sua sobrecarga, enquanto a AWS precisa provar que suas abstrações gerenciadas continuam confiáveis à medida que as cargas de trabalho dos clientes se tornam mais exigentes.

O Ganho de 75% Veio da Eliminação do Trabalho Operacional

O mecanismo central não foi apenas um grafo de orquestração mais inteligente; foi a transferência das responsabilidades de produção da equipe da nOps para serviços gerenciados.

A pilha anterior de Clara combinava frameworks de agentes com Amazon EKS. Kubernetes pode fornecer uma base sólida para serviços convencionais, mas um agente de IA adiciona comportamento com estado e não determinístico.

Um agente pode chamar diversas ferramentas, revisar seu plano, esperar por uma resposta lenta ou continuar uma sessão ao longo de várias interações do usuário. Esses comportamentos complicam timeouts, tentativas de repetição, observabilidade e planejamento de capacidade.

O AgentCore Runtime aborda a camada de hospedagem com sessões isoladas e escalabilidade gerenciada. A AWS descreve Runtime como a infraestrutura sob a lógica de agente controlada pelo cliente, e não como substituto dessa lógica.

Esse limite importa. Segundo as orientações do Runtime, os clientes continuam responsáveis por seu código e devem usar serviços de memória dedicados para contexto durável.

Assim, a nOps poderia se concentrar em como Clara interpreta uma solicitação FinOps, em vez de criar cada controle ao redor dela. Isso provavelmente encurtou o caminho entre um fluxo de trabalho experimental e um serviço capaz de atender clientes reais.

O acesso a ferramentas é outra fonte de trabalho operacional. Um agente FinOps precisa de acesso cuidadosamente limitado a serviços analíticos, metadados de contas e funções de otimização. Tratar cada conexão como uma chamada de função sem restrições criaria riscos de segurança e confiabilidade.

O AgentCore Gateway oferece um limite gerenciado para expor APIs e outros serviços como ferramentas de agentes. Ele pode centralizar autenticação, políticas de acesso e observabilidade fora do ambiente imediato de execução do agente.

A gestão de identidade também se torna mais importante quando um agente atua para muitas organizações. Clara não pode misturar as permissões, o contexto ou os resultados de um cliente com a sessão de outro.

Um sistema autogerenciado pode impor esses limites, mas a equipe precisa projetá-los, testá-los e mantê-los. O AgentCore fornece componentes destinados à identidade de cargas de trabalho e à autenticação de usuários finais.

Observability aborda um problema diferente. O monitoramento convencional pode mostrar que um serviço retornou um erro, mas os desenvolvedores de agentes também precisam entender a seleção de ferramentas, etapas intermediárias, latência e qualidade das respostas.

A documentação de observabilidade da AWS oferece suporte a logs e telemetria em Runtime, Gateway, Memory e ferramentas integradas. Isso fornece às equipes um local compartilhado para inspecionar falhas que abrangem diversas operações do agente.

Essas capacidades gerenciadas ajudam a explicar a mudança de prazo relatada. Elas reduzem o número de sistemas de produção que a nOps precisa montar antes que Clara possa atender clientes.

Elas não explicam toda melhoria de qualidade relatada. Respostas melhores podem resultar de prompts revisados, ferramentas mais limpas, recuperação aprimorada, avaliações mais robustas, modelos diferentes ou dados mais bem governados.

A conta da AWS não isola essas variáveis em um experimento controlado. A nOps reconstruiu partes de Clara ao mesmo tempo que mudou sua base de runtime, portanto diversas melhorias podem ter ocorrido simultaneamente.

Ainda assim, operações gerenciadas podem afetar a qualidade indiretamente. Rastros melhores ajudam desenvolvedores a localizar falhas, interfaces consistentes de ferramentas reduzem resultados ambíguos e um tratamento confiável de sessões impede que o contexto desapareça inesperadamente.

O resultado de quatro meses é, portanto, mais bem entendido como um mecanismo organizacional. O AgentCore permitiu que a equipe de Clara dedicasse mais esforço de engenharia ao comportamento do produto e menos à infraestrutura genérica de produção.

Esse mecanismo é mais transferível do que o percentual exato. Outra equipe pode não reproduzir uma redução de 75%, mas pode avaliar quanto de seu roadmap consiste em trabalho de runtime disponível em uma plataforma gerenciada.

Métricas Governadas Mantêm as Respostas de Clara Ancoradas

A migração do runtime não eliminou o requisito mais difícil de FinOps: Clara ainda precisa de definições consistentes para cada métrica financeira e operacional que utiliza.

As perguntas de FinOps muitas vezes parecem simples, mas escondem várias escolhas. “Por que os gastos aumentaram?” depende do período analisado, dos limites de serviço, das regras de alocação, dos descontos, dos compromissos e do tratamento de custos compartilhados.

Um modelo de linguagem não deve inventar essas definições a partir da formulação de cada solicitação. Se dois usuários fizerem perguntas semelhantes, eles precisam de cálculos baseados na mesma lógica de negócio governada.

A nOps manteve as Databricks Lakehouse Metric Views no caminho analítico. A Databricks define Metric Views como definições de métricas reutilizáveis e governadas no Unity Catalog, separando os cálculos de negócio das consultas individuais.

Essa arquitetura oferece a Clara uma camada semântica controlada. O agente pode traduzir a intenção de um usuário em uma tarefa analítica sem redefinir receita, utilização, economia ou cobertura a cada interação.

Essa divisão de trabalho é mais importante do que uma simples atualização de modelo. O modelo de linguagem lida com a ambiguidade da pergunta, enquanto a camada de métricas protege a consistência da resposta.

Considere um usuário perguntando se um compromisso do Amazon EC2 está sendo subutilizado. Clara precisa identificar as contas, regiões, famílias de instâncias, intervalo de tempo e tipo de compromisso relevantes.

O agente pode coordenar esse trabalho, mas os cálculos subjacentes devem vir de definições aprovadas. Caso contrário, uma resposta fluente pode mascarar uma aritmética inconsistente.

As Metric Views também ajudam a separar mudanças no produto da governança de dados. A nOps pode revisar os prompts ou a orquestração de Clara enquanto mantém uma definição estável da métrica em discussão.

Essa estabilidade apoia os testes. Os desenvolvedores podem comparar a interpretação e a narrativa do agente com resultados analíticos conhecidos, em vez de avaliar toda a resposta como um bloco inseparável.

A abordagem também limita o que o AgentCore precisa fazer. A AWS opera o runtime e os serviços relacionados, enquanto a Databricks continua responsável pelas definições de métricas governadas dentro da arquitetura de dados da nOps.

Este é um sistema multiplataforma, apesar do foco do título em amazon aws. Seu sucesso depende das interfaces entre o agente, os serviços da AWS, a lógica da nOps e a camada da Databricks.

Essas interfaces podem se tornar pontos de falha. Uma métrica correta não é útil se Clara chamar a ferramenta errada, fornecer filtros incorretos ou descrever o resultado com uma certeza sem respaldo.

O inverso também é verdadeiro. Uma solicitação encaminhada corretamente ainda pode produzir uma resposta enganosa se a definição da métrica excluir uma categoria de custo importante.

Por isso, a qualidade deve ser avaliada em vários níveis. As equipes precisam testar a seleção de ferramentas, a precisão dos parâmetros, a correção das métricas, a fidelidade da narrativa, as permissões e o resultado final da tarefa.

O framework AgentOps da AWS recomenda avaliar separadamente ferramentas, interações de conversa, sessões e comportamento em produção. Esse modelo se ajusta à arquitetura em camadas de Clara.

A análise governada também oferece uma resposta útil às preocupações sobre a autonomia dos agentes. Clara pode se comportar dinamicamente na camada de interação sem receber liberdade ilimitada sobre cálculos financeiros.

Para compradores empresariais, esse é o padrão mais crível. Uma interface conversacional deve facilitar o uso de dados governados, não substituir a governança pelo julgamento do modelo.

A lição vai além de FinOps. Agentes em vendas, operações, engenharia e pesquisa precisam de definições estáveis para os fatos que orientam decisões.

Trabalhadores do conhecimento podem aplicar o mesmo princípio ao material de apoio. Uma base de conhecimento de IA pesquisável ajuda a preservar fontes e contexto, mesmo quando uma interface de IA muda a forma como as informações são recuperadas.

A arquitetura de Clara mostra que a execução gerenciada e o conhecimento governado são complementares. O runtime controla como o trabalho acontece, enquanto a camada de métricas controla o significado das afirmações analíticas.

O Que os Números da nOps Não Comprovam

O caso sustenta a alegação de uma migração mais rápida, mas não prova que toda equipe de agentes deva substituir Kubernetes por AgentCore.

O número de 75% vem da nOps e da AWS. O relato público não fornece uma auditoria independente, uma discriminação detalhada do trabalho ou uma comparação controlada entre implementações equivalentes.

A linha de base também merece análise. Um plano de entrega projetado para 10–12 meses não é o mesmo que uma implantação concluída e medida ao longo desse período.

Os planos incluem premissas sobre equipe, revisões de segurança, trabalho de plataforma e requisitos de produto em mudança. Se essas premissas mudarem durante uma reconstrução, a comparação pode refletir mais do que a escolha de infraestrutura.

O resultado de quatro meses continua significativo como um resultado relatado por um cliente. Ele não deve ser tratado como uma garantia universal de desempenho do Amazon Bedrock AgentCore.

A qualidade das respostas apresenta uma questão semelhante. A AWS e a nOps afirmam que as respostas de Clara melhoraram, mas o estudo de caso disponível não publica um conjunto completo de avaliações nem pontuações comparativas.

Os leitores não conseguem determinar quanto da melhoria veio do AgentCore, de prompts revisados, de novas ferramentas, de mudanças nos dados, da seleção de modelos ou da experiência acumulada de desenvolvimento.

Isso não é motivo para descartar o resultado. É motivo para diferenciar uma história de implementação crível de um benchmark controlado.

O esforço de migração é outra incerteza. A nOps já operava na AWS por meio do Amazon EKS, o que pode ter reduzido o atrito organizacional e de rede ao adotar outro serviço da AWS.

Uma empresa que opere em outro ambiente poderia enfrentar mudanças maiores envolvendo identidade, rede, compras, conformidade e competências da equipe. Seu cronograma de migração poderia ser muito diferente.

A concentração em um fornecedor também merece atenção. O AgentCore oferece suporte a vários frameworks e modelos, mas um sistema de produção ainda pode ficar estreitamente vinculado aos serviços operacionais da AWS.

Empacotamento do runtime, políticas de Gateway, integrações de Identity, telemetria do CloudWatch e automação de implantação podem criar custos de mudança, mesmo quando o código do agente permanece portátil.

A pergunta correta não é se existe lock-in. Toda arquitetura de produção cria dependências. A pergunta é se as operações gerenciadas entregam valor suficiente para justificar essas dependências.

Algumas equipes ainda preferirão Kubernetes. Elas podem exigir hardware especializado, redes incomuns, agendamento personalizado, portabilidade rigorosa de infraestrutura ou controle direto sobre cada componente do runtime.

Grandes organizações de plataforma também podem distribuir seu investimento por muitos produtos de agentes. Uma base autogerenciada se torna mais fácil de justificar quando dezenas de equipes a compartilham.

Grupos menores de produto enfrentam uma economia diferente. Construir uma plataforma interna completa de agentes para uma ou duas aplicações pode consumir os recursos necessários para melhorar essas aplicações.

A pressão competitiva complica a decisão. O Google oferece desenvolvimento e implantação gerenciados de agentes por meio do Vertex AI, enquanto a Microsoft disponibiliza serviços de agentes hospedados em sua plataforma de nuvem.

Isso significa que a nOps não está validando a abordagem gerenciada apenas para a AWS. Também está ilustrando uma mudança mais ampla do mercado, na qual provedores de nuvem absorvem uma parcela maior da pilha de operações de agentes.

A concorrência entre provedores pode beneficiar compradores com melhores ferramentas e maior suporte a modelos. Ela também pode fragmentar interfaces de identidade, telemetria, avaliação e ferramentas entre planos de controle proprietários.

A segurança continua sendo uma responsabilidade compartilhada. Um serviço de identidade gerenciado não pode corrigir uma função excessivamente ampla, e um gateway não pode tornar segura uma ferramenta perigosa sem uma política apropriada.

Agentes de FinOps criam um risco particular porque podem influenciar compromissos de recursos e mudanças operacionais. Uma resposta equivocada pode se tornar cara se os usuários a tratarem como autorização, e não como análise.

A camada de dados governada de Clara limita uma categoria de erro, mas a revisão humana e os controles de política ainda importam para ações consequentes. O estudo de caso não elimina esses requisitos.

A interpretação mais forte é, portanto, mais restrita do que o título. A nOps afirma que chegou à produção muito mais rapidamente após adotar o AgentCore, preservando a análise governada e reduzindo o trabalho de infraestrutura.

O resultado torna a infraestrutura gerenciada de agentes mais difícil de ignorar. Ele não resolve todas as decisões de arquitetura.

O Que amazon aws Precisa Comprovar em Seguida

O próximo teste é saber se a vantagem de entrega relatada por Clara se sustenta em escala de produção, em revisões mensuráveis de qualidade e em futuras mudanças de plataforma.

O primeiro sinal a observar é a qualidade sustentada das respostas. A nOps deve ser capaz de demonstrar que Clara seleciona as ferramentas corretas, aplica parâmetros válidos, cita resultados governados e evita recomendações sem respaldo.

Pontuações agregadas de satisfação forneceriam apenas parte do quadro. Compradores de FinOps precisam de avaliações por tarefa que cubram precisão, completude, latência, permissões e as consequências financeiras dos erros.

Métodos de avaliação publicados fortaleceriam consideravelmente o caso. Eles ajudariam os leitores a separar os benefícios do runtime das melhorias causadas por modelos, prompts ou mudanças nos dados.

Se a nOps conseguir manter resultados melhores em um amplo conjunto de avaliações, a alegação de qualidade se tornará mais forte. Se o desempenho variar acentuadamente conforme a complexidade da conta ou o tipo de pergunta, o lançamento em quatro meses parecerá mais um marco inicial.

O segundo sinal é o comportamento operacional em escala. O AgentCore precisa lidar com mudanças de tráfego, sessões longas, falhas de ferramentas e isolamento de clientes sem recriar a carga operacional que a nOps tentou eliminar.

Os compradores devem acompanhar a latência, as sessões com falha, o comportamento de recuperação e o tempo que os desenvolvedores gastam diagnosticando incidentes. A infraestrutura gerenciada só justifica seu lugar se as operações permanecerem mais simples depois que a adoção crescer.

A AWS também precisará manter seus componentes observáveis à medida que os fluxos de trabalho dos agentes se tornarem mais complexos. Uma única solicitação de usuário pode atravessar Runtime, Gateway, ferramentas externas e uma plataforma analítica governada.

Os rastros precisam permitir que engenheiros acompanhem esse caminho sem expor dados confidenciais de clientes. Uma visibilidade fraca empurraria as equipes de volta para instrumentação personalizada e reduziria a vantagem da plataforma gerenciada.

O terceiro sinal é a flexibilidade arquitetural. A nOps deve conseguir revisar os frameworks, modelos, ferramentas e conexões de dados de Clara sem uma reescrita cara da plataforma.

A AWS atualmente posiciona o AgentCore como compatível com vários frameworks e provedores de modelos. Essa promessa só se torna significativa quando os clientes a exercitam em condições de produção.

Uma futura mudança de modelo oferece um teste útil. Se a nOps puder avaliar e implantar outro modelo compatível, preservando identidade, telemetria e governança de ferramentas, o design modular do AgentCore parecerá crível.

Se cada mudança importante exigir uma reconstrução específica para a AWS, o ganho inicial de velocidade poderá se tornar uma contrapartida de manutenção no longo prazo. Isso enfraqueceria o argumento contra a infraestrutura autogerenciada.

As respostas dos concorrentes também importam. Google e Microsoft continuarão fazendo alegações semelhantes sobre implantação mais rápida, governança e observabilidade integrada.

O mercado irá além das listas de recursos. As equipes empresariais compararão esforço de migração, qualidade de avaliação, resposta a incidentes, portabilidade e o tempo total de engenharia necessário após o lançamento.

Para a nOps, a evidência mais importante virá do uso contínuo de Clara. Perguntas mais complexas, adoção mais ampla por clientes e resultados confiáveis em produção mostrariam que a construção de quatro meses criou valor duradouro.

Para os desenvolvedores, a decisão começa com um inventário. Identifique quais partes do roadmap atual melhoram o agente e quais partes apenas mantêm seu runtime em operação.

Em seguida, teste a alternativa gerenciada em fluxos de trabalho reais, não em um prompt de demonstração. Inclua autenticação, dados governados, casos de falha, monitoramento e as perguntas mais difíceis dos clientes.

A história da nOps oferece à amazon aws um forte exemplo de cliente, mas a aceleração relatada de 75% é a alegação inicial. A avaliação duradoura depende de Clara continuar precisa, gerenciável e adaptável depois que a narrativa da migração perder força.

As equipes que avaliam seu próprio caminho devem fazer uma pergunta direta: assumir a propriedade do runtime cria valor para o cliente ou atrasa o trabalho que cria esse valor?