Built for the warehouse
floor that already exists
We didn't design a new arm or a new robot OS. We built the learning layer that runs on top of the arms your facility already operates.
Our Mission
One session to train a fleet. Not a per-arm, per-SKU bottleneck.
Automcore was built to solve a specific constraint — not warehouse robotics in general, but the exact failure mode that stops real distribution centers from scaling their picking operations: per-arm, per-SKU teach-in sessions that multiply programming cost with every arm you add and every new product that arrives.
Traditional approaches treat each arm as an independent system with its own programming state. That assumption worked when facilities ran 2–3 arms on fixed product catalogs. It fails at 12 arms and collapses at 40. Automcore's propagation model treats the fleet as a single learning unit — one session, every arm.
Founding Story
A distribution center in Fontana, 2019–2020
Angela Ferreira spent 14 months as an automation engineering lead at a distribution center in Fontana, California — part of a broader robotics deployment program across a regional DC network. Her job was to keep the robotic picking operation functional and expanding. The arms were capable: a mixed fleet of UR10e cobots and FANUC CR-14iA units, well-maintained, with consistent cycle times on the SKUs they knew.
The constraint arrived in the spring of 2020, when a major retail customer onboarded and brought 800 new SKUs onto the inbound manifest. Each SKU needed a teach-in session on each arm before it could be robotically picked. At roughly 2 hours per SKU per arm, across 12 arms, the math was 19,200 hours of programming work. Two robot programmers, working full shifts, would take months. The seasonal window was 6 weeks.
The facility triaged. High-velocity SKUs got arms. Long-tail SKUs stayed manual. The triage decision was being made by two programmers who couldn't possibly work fast enough — not by any operational logic. Angela documented the constraint formally: the bottleneck wasn't pick rate, gripper payload, or arm reach. It was the O(arms × SKUs) teach-in problem. The fleet scaled badly not because the hardware was wrong, but because the programming model assumed one programmer per arm per SKU.
Automcore's founding question was direct: if one arm completed a training session on a new SKU, could that grasp knowledge — the pose estimation, the approach trajectory, the force calibration — be compressed and propagated to every other arm on the facility LAN? Not shared loosely, but distributed with a confidence gate on the receiving end, so each arm validated the model independently before using it in production. That question became the product. Angela co-founded Automcore in Los Angeles in 2021.
Our Approach
Three positions we hold
Automcore is a software layer — not a robot manufacturer
We do not build arms. We do not sell end effectors. We do not replace your facility's existing controllers. Automcore connects to the arm controllers your facility already operates — via URScript, FANUC R-30iB socket interfaces, ABB EGM, MotoROS2, and KUKA FRI — and adds a grasp learning and propagation layer on top. Your existing fleet is the starting point. We add the learning model that removes the per-arm, per-SKU programming overhead.
Fleet learning is a network effect problem
Every arm that trains adds to the model quality for every other arm. A 16-arm fleet that runs Automcore for 6 months has a materially better grasp model than a 4-arm fleet — not because of more hardware, but because of more training signal propagated across the network.
Confidence gating over silent failure
An arm that pretends to know a SKU's grasp geometry when it doesn't is worse than an arm that flags it. Automcore enforces validation before any arm uses a propagated model in production. We'd rather a facility operator know there's a gap than discover it through a dropped pallet.
Learn more about how Automcore works.
Read the technical overview of the propagation engine, or request a demo to see it against your facility configuration.