A prioridade de tarefas do RCS não era um problema na era das frotas pequenas. Com uma dúzia de robôs, o primeiro a chegar primeiro a ser atendido funcionava bem o suficiente: bateria baixa significava ir carregar, e um pedido urgente podia ser inserido à mão sem quebrar nada. Mas quando uma frota cruza certo limiar, o agendamento deixa de ser despacho e se torna um verdadeiro trade-off. Tarefas de onda precisam de vazão, pedidos urgentes precisam de lead time, e o carregamento precisa que a frota continue online — e os três competem pelos mesmos robôs. O RCS, o sistema de controle de robôs situado entre o WMS e a frota, passa cada dia alocando capacidade entre esses três tipos de tarefas.

Quando a frota cresce, a prioridade de tarefas do RCS vira um problema real

Comecemos pelos dados. Segundo a Interact Analysis, os embarques acumulados de robôs móveis se aproximavam de 2.1 million de unidades até o fim de 2025, representando cerca de $18 billion em receita, enquanto o número de sites de clientes implantando robôs móveis cresceu de pouco mais de 9,000 em 2020 para mais de 53,000. A história da indústria nos últimos cinco anos foi a mudança de "algumas dezenas de robôs em piloto" para "uma frota como unidade operacional".

No entanto, a mesma empresa rebaixou sua projeção em uma atualização de meados de 2025: cortou a previsão de AMR do ano em $800 million, reduziu a taxa de crescimento composto em cinco anos de 26% para 21%, e baixou a projeção de receita para 2030 para $15.6 billion, citando a disrupção tarifária e uma postura de espera nos gastos de capital dos clientes. O rebaixamento merece uma pausa. Não significa que o problema de agendamento esteja diminuindo — muito pelo contrário. Nos anos em que a expansão desacelera, os operadores extraem mais utilização das frotas que já têm, e quanto maior a utilização, mais agudo o conflito entre os tipos de tarefas.

Um segundo sinal vem da Amazon. Em June 2025, a empresa anunciou sua implantação de robô de número um milhão, espalhada por mais de 300 instalações, ao lado do DeepFleet, um modelo de IA generativa criado para coordenar o movimento dos robôs, que segundo a empresa pode melhorar a eficiência de deslocamento dos robôs em 10%. Esse número é uma afirmação do fornecedor, não uma medição verificada de forma independente, e a distinção importa. Mas a direção é clara: quando o alvo de coordenação cresce de dezenas de máquinas para um milhão, o agendamento não pode mais ser "regras escritas em pedra". Tem que se tornar algo que o sistema aprende.

Um dilema real: quando pedidos urgentes roubam os robôs da onda

Antes da temporada de pico de 2024, um armazém de fulfillment de e-commerce no sudoeste dos Estados Unidos enfrentou o caso de manual. Na noite de uma grande promoção, pedidos urgentes despejaram, e o RCS ligou a prioridade preemptiva: tarefas urgentes de alta prioridade podiam interromper tarefas de onda de baixa prioridade em andamento e puxar os robôs.

O corte foi salvo, e os pedidos urgentes daquela noite foram expedidos mais ou menos no prazo. O preço apareceu na segunda metade da noite. As tarefas de onda interrompidas continuavam sendo adiadas, as ondas seguintes escorregaram todas, e em um momento as estações de picking ficaram ociosas com robôs esperando mercadorias que não tinham chegado — os veículos estavam esperando o trabalho, não o contrário.

O caso ilustra um fato fácil de perder: a preempção não é grátis. Ela não elimina o atraso; ela o realoca, movendo o custo dos pedidos urgentes para as tarefas de onda de outra forma. Uma política de prioridade é, em sua essência, uma decisão sobre quem arca com o custo de congestionamento do sistema.

Frota de AMR operando no piso de um armazém, com um robô acoplado a uma estação de carregamento

Três estratégias de prioridade de tarefas do RCS: um arcabouço de trade-off de agendamento

Na prática, as abordagens da indústria para o conflito triplo se dividem em três grandes estratégias, cada uma com seus custos:

Estratégia Lógica Melhor ajuste Custo
Prioridade estática Ranqueamento fixo, ex.: urgente > onda > carregamento Frotas pequenas, mix de tarefas homogêneo As ondas passam fome quando pedidos urgentes são frequentes; o carregamento é sistematicamente negligenciado
Pontuação ponderada Cada tipo de tarefa é pontuado dinamicamente por tempo de espera, pressão do prazo e estado do veículo; a maior pontuação vai primeiro Tarefas mistas, carga volátil Os pesos precisam de recalibração contínua; o ajuste é caro e o desvio degrada o desempenho
Preemptiva com salvaguardas Pedidos urgentes podem preemptar, mas tarefas de onda mantêm uma fatia mínima garantida; o carregamento é reservado em janelas Frotas grandes, temporada de pico A mais complexa de implementar; exige prever o estado da frota e a chegada de tarefas

Nenhuma delas é a resposta padrão. Minha observação é que a maioria das frotas maduras executa uma variante da terceira: a preempção é permitida, mas o lado preemptado recebe proteção contra inanição — por exemplo, uma tarefa de onda escala automaticamente em prioridade depois de ser adiada um número determinado de vezes. A questão não é qual estratégia escolher, mas se a operação aceita a premissa de que qualquer regra estática falhará sob alguma carga, e que a própria política precisa de feedback.

A contraintuitiva: o carregamento é a variável oculta da vazão

Dos três tipos de tarefas, o carregamento é o mais fácil de subestimar. A intuição diz que o carregamento não produz pedidos, então deveria ficar por último. Um armazém seguiu essa intuição e fixou a prioridade de carregamento no mínimo, deixando que apenas robôs abaixo de um limiar de bateria fossem carregar.

Então, numa noite de temporada de pico, uma grande fatia da frota atingiu o limiar quase ao mesmo tempo. Formou-se uma fila nas estações de carregamento, a disponibilidade da frota despencou nas primeiras horas da madrugada, e a vazão do site caiu junto. A correção dos engenheiros foi contraintuitiva: eles elevaram a prioridade das tarefas de carregamento e passaram para o carregamento fragmentado de oportunidade — completando a carga entre tarefas sempre que um robô passava por um carregador — combinado com janelas de carregamento concentrado nos horários de menor movimento. A curva de disponibilidade se achatou, e o sistema ficou mais estável, não menos.

O trade-off merece ser destrinchado. O custo real de uma tarefa de carregamento não é a eletricidade. São veículos saindo de operação no momento errado, juntos. Numa frota de alta utilização, o carregamento é uma pré-condição da vazão, não uma reflexão tardia. Tratá-lo como tarefa de baixa prioridade "quando houver tempo" planta uma bomba-relógio no agendamento.

Por que os três tipos de tarefas entram em conflito por projeto

O conflito é estrutural, não gerencial. Os três tipos de tarefas vivem em três escalas de tempo diferentes: tarefas de onda são planejadas por hora e altamente previsíveis; pedidos urgentes chegam por minuto e são essencialmente imprevisíveis; o carregamento é regido por curvas de bateria e pela contagem física de carregadores, o que o torna, no fundo, um problema de satisfação de restrições.

Um nível abaixo, suas funções objetivo nunca estiveram alinhadas. Tarefas de onda querem maximizar a vazão, pedidos urgentes querem minimizar a latência, e o carregamento quer maximizar a disponibilidade da frota. Cada dia, o RCS executa um trade-off online entre os três objetivos, e qualquer regra que otimize apenas um — "sempre priorize pedidos urgentes", por exemplo — paga por isso nas outras duas dimensões. É também por isso que quanto maior a frota, mais rápido as regras escritas à mão ficam sem saída.

Julgamento de tendência: a prioridade de tarefas do RCS está migrando de motores de regras para otimização baseada em aprendizado

Juntando os dados e os casos, meu julgamento é que nos próximos três a cinco anos, o agendamento RCS convencional vai migrar de "humanos escrevem regras e ajustam parâmetros" para a otimização baseada em aprendizado de "treinar em simulação, inferir online". Três razões: primeiro, a escala da frota — 2.1 million de unidades acumuladas em 53,000 sites — já tornou o ajuste manual insustentável; segundo, práticas como o DeepFleet da Amazon mostram que operadores líderes estão substituindo regras por modelos para a coordenação em nível de frota; terceiro, a simulação madura de gêmeos digitais permite que uma política ensaie milhares de temporadas de pico numa frota virtual antes de tocar numa frota real.

O julgamento tem uma pré-condição, porém. O agendamento baseado em aprendizado precisa de dados operacionais de alta qualidade como combustível, e a governança de dados da maioria dos armazéns ainda está no estágio "bom o suficiente". O algoritmo não é o gargalo. Os dados são.

O que deixa uma pergunta em aberto. Quando a própria política de agendamento se torna um sistema que aprende, a equipe de operações do armazém ainda precisa manter a mão na substituição manual de prioridade? E se sim, em que granularidade — ajustando alguns parâmetros de peso, ou assumindo o controle de um robô individual numa emergência? Ainda não há uma resposta padrão, mas a resposta provavelmente moldará como será a próxima geração de produtos RCS.

Por Dr. Chen, pesquisador de cadeia de suprimentos

Traduzido do inglês. Em caso de divergência, prevalece a versão em inglês.