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, além de contribuir 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 expertise 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 focada em reinventar os 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 às 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 as empresas 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 motivo número um pelo qual os compradores – CFOs, contadores, etc. – não iriam com a 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 é limitada 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 seu caminho 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 a sua empresa ao longo de anos por uma agência de consultoria de terceiros. Em seguida, uma vez que o produto é terminado, os consultores saem sem manutenção, melhorias de recursos ou suporte. Os engenheiros revolucionariam.

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 os sistemas ERP tradicionais, como o SAP ou o Oracle. Quais são as diferenças arquitetônicas fundamentais 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 escala. Para preservar as melhores práticas, eles bloquearam grandes partes dos sistemas centrais 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 da DOSS de um cliente 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 escala para entregar soluções de 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 construam 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 explosão. 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 infraestrutura empresarial desde cedo, o sistema está configurado para distribuição agente por completo. O que costumava levar equipes de consultores meses e anos para fazer agora pode ser paralelizado em 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 de negócios não são unificados em uma única fonte de verdade?

O problema mais comum é que as decisões são tomadas com base em informações desatualizadas 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 desmorona na prática. Eles executam operações em todo o varejo, atacado, DTC e cafés nos EUA e no Japão, mas estavam gerenciando tudo em sistemas desconectados 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 o lançamento de um grande varejista que prejudicou uma relação de varejo importante. 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 forma real 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, expedindo 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 fazer perguntas sobre.

Em sua 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.

As implementações de ERP historicamente exigiram grandes equipes de consultores e meses – ou mesmo anos – de implantação. Como a IA muda a economia e a complexidade de implementar 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. Nós 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 grande maioria dos construtores não tiraria proveito disso; no entanto, eles nunca são incentivados a se mover com ritmo e qualidade.

Além disso, a proporção de gastos de consultoria para gastos de software em um engajamento de ERP tradicional executa aproximadamente 9:1, então você está gastando nove dólares em consultores para cada dólar que você gasta no software em si. Para uma grande empresa, isso é extremamente doloroso. Para negócios de mercado médio, é proibitivo. Então, eles ou aceitam software que não se ajusta realmente à forma como operam, atrasam o projeto ou abandonam-no no meio do caminho.

A IA muda completamente a unidade econômica disso. Em vez de um engajamento de consultoria, uma implementação da Doss é um código-fonte. À medida que os 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 slide decks longos 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 é comoditizar todos os aplicativos de negócios em 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 os 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 negócio com o 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 exemplo excelente é 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 de 3PL em execução em cópia e cola manual de pastas FTP. 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 negócio tem uma versão diferente desse problema, e você não pode totalmente antecipar até que esteja dentro dos dados deles. O trabalho é tirar uma impressão precisa de como o negócio realmente opera, não mapear seus dados em um modelo genérico e esperar que se ajuste.

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 negócios. 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 tomada 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 por completo; é 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 pilhas de software existentes. Na 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 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 sobre ele, na realidade, um servidor MCP precisa de padrões de design muito específicos. A maioria dos servidores MCP hoje na verdade introduz um maior bloat de janela de contexto e explode o desempenho.

No entanto, a questão mais profunda é o modelo de implementação. Em um ERP tradicional, a configuração do sistema é armazenada no próprio sistema. 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. Isso é o pré-requisito para a IA realmente operar no sistema em vez de apenas sentar sobre ele.

À medida que a IA se torna capaz de gerar fluxos de trabalho e interagir diretamente com sistemas operacionais, como você acha que a interface tradicional de software de empresa irá 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 dele.

O que estamos construindo é uma interface componível, que trata a interface como um construtor de sites. A interface em si também é respaldada 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, e não em torno de como o software foi configurado. À medida que a IA lida com mais da execução subjacente do fluxo de trabalho, 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 de julgamento. 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 quando competem contra plataformas empresariais estabelecidas?

Os incumbentes têm o problema oposto ao das startups. Eles têm enormes bases instaladas para proteger. Cada decisão arquitetônica que eles tomam deve 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 onde a receita é impulsionada pela função específica que a Doss está procurando eliminar – consultores de serviços profissionais. Dado que os usuários gastam nove dólares em consultores para cada dólar que gastam no 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, e não uma camada sobre ela. 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 composta onde cada implantação torna o sistema melhor, e os agentes de implantaçã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 a convicção de que os sistemas empresariais seriam capazes de se construir sozinhos. Três anos depois, entramos na Fase 2 da Doss: a implementação auto-dirigida 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 de fornecimento antes que 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. É a versão de software de operações que estamos construindo.

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