Arnav Mishra, Co-Fundador e CTO da Doss – Série de Entrevistas

Arnav Mishra, Co-Fundador e CTO da Doss, é um engenheiro full-stack e líder técnico com uma formação que abrange startups em estágio inicial e sistemas de infraestrutura em larga escala. Antes de co-fundar a Doss, ele foi um dos engenheiros fundadores da Siteline, onde construiu sistemas centrais, incluindo arquitetura de permissões, integrações de ERP e estruturas de automação, enquanto também contribuía para o recrutamento, operações de receita e cultura da empresa. No início de sua carreira, ele ocupou cargos de engenharia na Rubrik e fez estágios em empresas como Uber e VMware, desenvolvendo especialização em infraestrutura de nuvem, sistemas de dados e automação. Além de seu trabalho técnico, ele esteve ativamente envolvido em mentorias e desenvolvimento de talentos por meio de organizações como Techquitable Futures e Contrary, refletindo um compromisso mais amplo de apoiar a próxima geração de engenheiros.

Doss é uma empresa de software empresarial moderna que se concentra em reinventar sistemas ERP tradicionais por meio de sua Plataforma de Recursos Adaptáveis (ARP), uma plataforma de operações flexível e nativa em IA projetada para unificar e automatizar fluxos de trabalho de negócios. Construída como uma alternativa componível a soluções ERP legadas, a Doss permite que as empresas gerenciem estoque, compras, finanças e entrega dentro de um único sistema que se adapta às operações do mundo real, em vez de forçar processos rígidos. Sua plataforma combina uma camada de dados centralizada, fluxos de trabalho sem código e análises em tempo real, permitindo que os negócios implantem rapidamente, integrem com ferramentas existentes e evoluam continuamente suas operações sem implementações longas ou consultores caros.

A motivação para construir a Doss remonta a Wiley, que viu o software legado disruptar o negócio de manufatura de seu pai, e ambos mais tarde viram problemas semelhantes em primeira mão enquanto trabalhavam com fábricas e cadeias de suprimentos de hardware. Como essas experiências moldaram sua decisão de co-fundar a Doss e repensar os sistemas ERP do zero?

Antes da Doss, eu era o engenheiro fundador de uma startup de FinTech. O principal motivo pelo qual os compradores – CFOs, contadores, etc. – não iriam com nossa solução era porque estavam “muito ocupados implementando um ERP”. Quando eu me aprofundei mais no arcaico mundo do ERP, fiquei impressionado com o modelo de implementação existente.

O que eu continuei vendo foi o mesmo fracasso fundamental: a implementação leva meses ou anos, custa centenas de milhares a milhões de dólares e é engessada inteiramente por consultores humanos com faturamento por hora. Em seguida, uma vez que o ERP é enviado, ele para de mudar. O negócio continua evoluindo; o sistema não. Isso é um problema arquitetônico, não um problema de configuração. Você não pode patchar para fora disso.

Como um construtor de software, a comparação mais próxima que eu podia pensar era a seguinte: imagine um mundo em que a ferramenta mais importante que você usa – como um desenvolvedor, digamos GitHub – foi construída especificamente para apenas sua empresa ao longo de anos por uma agência de consultoria de terceiros. Em seguida, uma vez que o produto está pronto, os consultores saem sem manutenção, melhorias de recursos ou suporte. Os engenheiros se revoltariam.

Nenhuma empresa de tecnologia moderna pode operar nesse modelo. Wiley e eu chegamos à mesma conclusão: a única maneira de consertar isso era construir do zero.

A Doss se posiciona como uma plataforma de operações nativa em IA projetada para substituir sistemas ERP tradicionais como o SAP ou o Oracle (ORCL ). Quais são as principais diferenças arquitetônicas que tornam um ERP nativo em IA possível hoje que não eram viáveis há uma década?

O Oracle e o SAP foram construídos em uma era em que, para alcançar a distribuição maximizada, eles precisavam simplificar o plano de configuração de um ERP para ser um editor baseado em GUI que consultores relativamente não técnicos pudessem entregar em larga escala. Para preservar as melhores práticas, eles bloquearam grandes partes do sistema central e apenas permitiram a composabilidade nas bordas. No entanto, na realidade, quando você olha para o espectro de todos os negócios do mundo, suas aplicações de negócios precisam de flexibilidade máxima.

O que o mundo nativo em IA habilita é a transformação da engenharia de software de um ofício para uma máquina industrializada. Já não precisamos de artesãos de software para criar sistemas de código manualmente; em vez disso, estamos nos movendo para um mundo em que a produtividade de software é um fator de computação e tokens.

A Doss foi arquitetada com exatamente isso em mente.

Construímos o ZSL, uma linguagem de domínio específico declarativa (DSL) que descreve a implementação completa do cliente da Doss em código. Pense no que o “Terraform” fez para o esforço de Infraestrutura como Código, mas aplicado à lógica de aplicativos de negócios. Ao definir ERPs em uma linguagem de programação de baixa dimensionalidade, somos capazes de implantar agentes em larga escala para entregar soluções ERP.

Uma vez que o ZSL foi escrito, a parte mais importante da arquitetura foi incorporar as melhores práticas na própria plataforma para evitar que os agentes construíssem implementações de baixa qualidade. Nossa equipe entregou um sistema distribuído escalável com um agendador de nível de kernel para lidar com a carga de trabalho de ERP em surtos. Além disso, construímos um sistema de banco de dados HTAP que combina as partes mais importantes de um banco de dados transacional como o Postgres e as capacidades analíticas de um Data Warehouse.

Ao construir a plataforma para ter força de empresa de nível empresarial desde cedo, o sistema está configurado para distribuição agente inteiramente. O que costumava levar equipes de consultores meses e anos para fazer agora pode ser paralelizado em larga escala usando infraestrutura agente em nosso sistema de loop fechado proprietário.

Muitas empresas ainda dependem de planilhas e ferramentas fragmentadas para compras, estoque e gerenciamento de pedidos. Quais são os principais pontos cegos operacionais que surgem quando os dados centrais do negócio não são unificados em uma única fonte de verdade?

O problema mais óbvio é que as decisões são tomadas com base em informações estaleadas ou incompletas. Se seus dados de estoque vivem em um lugar, seus pedidos de compra em outro e seus pedidos de venda em um terceiro, você está sempre reconciliando, manualmente, lentamente e após o fato. Até que alguém perceba que o estoque está errado ou que um fornecedor está atrasado, já é um problema no negócio.

Verve Coffee Roasters é um bom exemplo de onde isso se desintegra na prática. Eles operam em operações em varejo, atacado, DTC e cafés nos EUA e no Japão, mas estavam gerenciando tudo em sistemas desconexos sem visibilidade de estoque em tempo real. Eles estavam ficando sem seu próprio café em locais de alto tráfego e atingiram estoque crítico durante um lançamento de varejista importante que prejudicou uma relação de varejo-chave. Os dados existiam em algum lugar; eles simplesmente não estavam conectados de uma maneira que permitisse que alguém agisse sobre eles a tempo.

A questão mais sutil é que a fragmentação esconde a verdadeira forma das operações. Você não pode ver a relação entre um atraso upstream e um problema de entrega downstream se essas duas coisas vivem em ferramentas separadas. Você acaba gerenciando sintomas, agilizando pedidos, construindo estoque de segurança e executando verificações manuais em vez de entender o que realmente está acontecendo. Um sistema unificado não apenas economiza tempo de reconciliação. Ele muda o que você pode até mesmo ver e questionar.

Na essência, imagine executar um negócio empresarial sem acesso a um sistema de controle de versão (Git), uma ferramenta de observabilidade (DataDog) ou um banco de dados centralizado para consultar informações.

Implementações de ERP historicamente exigiram grandes equipes de consultores e meses – ou até anos – de implantação. Como a IA muda a economia e a complexidade da implementação de software operacional dentro de negócios reais?

O modelo de implementação tradicional é o resultado emergente de práticas de software de gerações antigas. Já não vivemos mais naquele mundo.

Há um incentivo perverso nas implementações de ERP hoje – quanto mais tempo a implementação leva e menos eficaz ela é, mais dinheiro os implementadores recebem. A maioria dos construtores não se beneficiaria disso; no entanto, eles nunca são incentivados a se mover com rapidez e qualidade.

Além disso, a relação entre o gasto com consultoria e o gasto com software em um engajamento de ERP tradicional é de aproximadamente 9:1, então você está gastando nove dólares com consultores para cada dólar que você gasta com o software em si. Para uma grande empresa, isso é extremamente doloroso. Para empresas de mercado médio, é proibitivo. Então, elas ou aceitam um software que não se ajusta realmente à forma como elas operam, adiam o projeto ou o abandonam parte do caminho.

A IA muda completamente a economia disso. Em vez de um engajamento de consultoria, uma implementação da Doss é um código-fonte. À medida que nossos tempos de implementação continuam a diminuir, somos capazes de alinhar os incentivos com um modelo “pague por entrega” em vez de “pague à medida que vai”. Quando o negócio muda, o sistema muda com ele. A necessidade de salas de consultores e slides de longa duração não é mais relevante.

O sucesso na Doss significa substituir o gasto global de US$ 1,86 trilhão em serviços de TI por implementação e manutenção agente usando nosso ZSL como a linguagem para software de aplicativos de negócios. O sucesso na Doss é commoditizar todos os aplicativos de negócios em larga escala.

Você implantou a Doss com empresas que operam em ambientes do mundo real, como manufatura, logística e bens de consumo. Quais são alguns dos desafios inesperados que surgem quando a IA encontra dados operacionais desordenados?

O desafio raramente é a IA. É os dados que você está pedindo que ela raciocine sobre.

Cada empresa com a qual trabalhamos acumulou anos de soluções operacionais. Os dados tecnicamente existem, eles simplesmente não vivem em nenhum lugar que os funcionários, muito menos os sistemas agente, possam agir de forma confiável.

Um ótimo exemplo é um fabricante de móveis alemão que cria peças feitas sob medida. Quando entramos, eles tinham 10 anos de dados históricos espalhados por 8 formatos de arquivo personalizados com 11 objetos de dados diferentes e uma sincronização 3PL em execução em pastas de FTP por cópia e cola manual. A lógica de negócios era específica, com dimensões personalizadas, configurações, métodos de pagamento e locais de showroom, e todo o sistema precisava funcionar em alemão. Não há esquema pronto para uso para isso. Eles tinham que pagar milhares de euros sempre que queriam alterar opções de configuração simples, como as opções de status para um pedido de compra.

O desafio não é a complexidade técnica de nenhuma peça. É que cada empresa tem uma versão diferente desse problema, e você não pode totalmente antecipar até que você esteja dentro de seus dados. O trabalho é tirar uma impressão precisa de como o negócio realmente opera, não mapear seus dados para um modelo genérico e esperar que se encaixe.

Para construir uma solução que funcione para o mundo real, você precisa de uma plataforma com flexibilidade máxima. Somente então a IA pode ser útil para entender o modelo de dados subjacente com o qual está trabalhando e construir o modelo que funciona para cada cliente.

Há muita discussão sobre copilotos de IA e agentes autônomos em software de negócios. Onde você vê a IA adicionando o maior valor nos fluxos de trabalho operacionais hoje, e onde a supervisão humana ainda permanece essencial?

Em escala, a IA tem a capacidade de disruptar todo o trabalho operacional.

No horizonte de curto prazo, os modelos e agentes proprietários da Doss devem ser capazes de transformar os núcleos de consultores técnicos na implementação de aplicativos de negócios, bem como os de consultores de gestão na entrega de recomendações estratégicas. A Doss terá o maior repositório de dados estruturados e co-localizados que representam tanto esquema quanto informações operacionais para empresas. Nossos agentes podem usar esses dados para entregar recomendações escaláveis.

O valor mais claro hoje é mais específico do que isso. É no trabalho que é repetitivo, baseado em regras e atualmente feito por pessoas que têm outras prioridades mais estratégicas: processamento de pedidos de compra, reconciliação de estoque e roteamento de decisões de entrega. Essas tarefas têm entradas e saídas bem definidas, e a IA pode lidar com elas de forma confiável em escala.

Por enquanto, a supervisão humana é essencial em qualquer lugar onde o custo de uma decisão errada é alto, e o sistema ainda não tem contexto suficiente para ter confiança. Hoje, o modelo certo não é agentes autônomos substituindo a tomada de decisão humana como um todo; é agentes lidando com o trabalho de alto volume e bem definido para que as pessoas possam se concentrar nas decisões que realmente exigem seu julgamento.

Muitas empresas estão tentando camada de IA sobre sistemas de software existentes. Em sua opinião, por que retrofitar sistemas legados com IA frequentemente falha em comparação com a construção de IA diretamente na fundação da plataforma?

Os sistemas legados não foram construídos para serem raciocinados pela IA. Os modelos de dados, as APIs, a forma como as informações são estruturadas, tudo isso foi projetado para humanos interagirem com interfaces. Quando você tenta camada de IA sobre isso, você está pedindo que ela trabalhe em torno de restrições com as quais ela não foi projetada para trabalhar.

Mesmo se você tentar jogar um servidor MCP em cima, na realidade, um servidor MCP precisa de padrões de design extremamente específicos. A maioria dos servidores MCP hoje na verdade introduz um maior bloat de janela de contexto e explode o desempenho.

No entanto, o problema mais profundo é o modelo de implementação. Em um ERP tradicional, a configuração do sistema é armazenada no sistema em si. Não é um código que você possa ler, testar ou versionar. Não há como um agente entender o que o sistema está fazendo, muito menos mudá-lo com segurança. Construímos o ZSL especificamente para que a configuração seja uma base de código adequada: legível, testável e implantável em um sistema de loop fechado. Estamos construindo um ciclo de vida de desenvolvimento de software (SDLC) totalmente agente. Essa é a pré-requisito para que a IA possa realmente operar no sistema em vez de apenas sentar em cima dele.

À medida que a IA se torna capaz de gerar fluxos de trabalho e interagir diretamente com sistemas operacionais, como você acha que a interface do software de empresa tradicional evoluirá?

A questão da interface é realmente sobre quem precisa usar o sistema. Atualmente, as interfaces de ERP são construídas em torno de um pequeno conjunto de usuários poderosos, as pessoas que foram treinadas no sistema durante a implementação. Todos os outros ou não podem usá-lo ou obtêm uma versão degradada.

O que estamos construindo é uma interface componível, que trata a interface como um construtor de site. A interface em si também é apoiada pelo ZSL de loop fechado. Cada pessoa, o CFO, o gerente de armazém, o analista de cadeia de suprimentos, obtém um painel e vistas de dados compostas em torno de como eles realmente trabalham, não em torno de como o software foi configurado. À medida que a IA lida com mais da execução do fluxo de trabalho subjacente, a interface se torna menos sobre entrada de dados e mais sobre visibilidade e tomada de decisão. Você precisa ver o que está acontecendo, entender por quê e tomar decisões. O software deve lidar com o resto.

Startups como a Doss estão entrando em um mercado dominado por incumbentes com décadas de existência. Quais são as vantagens que as startups nativas em IA têm ao competir contra plataformas de empresa estabelecidas?

Os incumbentes têm o problema oposto ao das startups. Eles têm bases instaladas enormes para proteger. Cada decisão arquitetônica que eles tomam tem que ser compatível com versões anteriores. Eles podem adicionar recursos de IA a produtos existentes, mas não podem reconstruir os sistemas subjacentes sem quebrar tudo que é executado neles. Isso não é uma falha de ambição; é estrutural.

Em ERP específico, eles também estão sobrecarregados com decisões de negócios que os levaram por um caminho em que a receita é impulsionada pela função específica que a Doss está tentando eliminar – consultores de serviços profissionais. Dado que os usuários gastam nove dólares com consultores para cada dólar que eles gastam com o software em si, a capacidade de transformar 90% de sua receita de fonte é insustentável para grandes incumbentes.

Um sistema nativo em IA pode ser projetado desde o início para que a IA seja parte da arquitetura central, não uma camada em cima. O modelo de implementação, o modelo de dados e a forma como a configuração funciona são todos projetados com a IA como um participante de primeira classe. Essa é uma vantagem de compounding, onde cada implantação torna o sistema melhor, e os agentes de implementação se tornam mais capazes com cada novo cliente. Esse tipo de loop de melhoria não existe em um sistema em que a implementação ainda é um engajamento de consultoria humana.

Olhando para o futuro, como você vê a IA transformando o “sistema operacional” de um negócio nos próximos cinco a dez anos, particularmente em áreas como visibilidade da cadeia de suprimentos, tomada de decisão em tempo real e operações automatizadas?

Fundamos a Doss com base na convicção de que os sistemas de empresa seriam capazes de se construir sozinhos. Três anos depois, entramos na Fase 2 da Doss: a implementação autodirigida agente. A plataforma já pode gerar, validar e evoluir o sistema de um cliente em vez de confiar na configuração manual de consultores, e ela melhora com cada implantação.

A direção para a qual isso está indo é um sistema que está sempre em sincronia com o negócio. Hoje, a lacuna entre como um negócio opera e o que o software sabe sobre ele é de meses ou anos. O sistema foi configurado em um momento no tempo e não mudou desde então. O que se torna possível quando essa lacuna se fecha, quando o sistema se adapta em tempo real à medida que o negócio muda, é uma categoria diferente de capacidade operacional. Visibilidade em tempo real não é apenas relatórios mais rápidos; é a capacidade de capturar uma interrupção na cadeia de suprimentos antes que ela se torne uma falha de entrega. Operações automatizadas não são apenas sobre eficiência; é a capacidade de executar um negócio mais complexo com a mesma equipe. Essa é a versão do software de operações que estamos construindo.

Obrigado por suas respostas detalhadas, leitores que desejam aprender mais devem visitar Doss.