Data is scattered
Mission evidence sits across S3 buckets, ROS bags, MCAP files, videos, logs, dashboards, and engineer notebooks.
Founding AE application artifact
A territory plan for Alloy's first repeatable sales motion.
The plan narrows the market from "robotics companies" to field-deployed autonomy teams with urgent mission-data pain, clear buyers, named accounts, and testable outbound wedges.
territory model
ANZ field robotics + US autonomy startups
pipeline focus
fit score
ICP filters: field data,
urgency, buyer access
ANZ defense
mining autonomy
US drones
GTM summary
-
Lead with mission-data pain
Debugging, reporting, and scenario mining are easier to sell than generic data storage.
-
Start with four wedges
Defense maritime, mining inspection, ag robotics, and drone logistics.
-
Beat internal build
Position against S3, scripts, Foxglove, notebooks, and data-platform maintenance.
GTM thesis
The pain starts after the mission.
Replay does not scale
Teams cannot manually inspect every three-hour mission to find the one failure customers care about.
Patterns stay hidden
A single failure is obvious. Finding all similar failures across robot versions, sites, and conditions is the hard part.
Learning is delayed
Debugging insights, scenario libraries, training data, and customer reports are still stitched together by hand.
Technical stack
MCAP and rosbag are the recording layer, not the workflow.
The sales motion should show respect for the existing robotics stack while naming the gap above it: cross-mission discovery, summaries, scenario search, and auditable reports.
01
Robot streams
Camera, LiDAR, IMU, GPS, autonomy state, diagnostics.
02
Mission files
MCAP, ROS 1 bag, rosbag2 SQLite or MCAP.
03
Raw storage
S3, GCS, Azure Blob, local drives, customer buckets.
04
Catalog
Mission IDs, robots, topics, versions, time ranges, access.
05
Extracted data
Time-series DBs, Parquet, Iceberg, dashboards, notebooks.
06
Search
Logs, events, embeddings, similarity, issue windows.
ALLOY
Mission memory
Plain-English search, reports, scenarios, replay links, evidence.
Named-account focus
Start where field evidence is expensive.
ANZ wedge
local proofAnduril Australia
Ghost Shark XL-AUV sea trials
OCIUS Technology
Persistent Bluebottle USV patrol data
Emesent
GPS-denied mine autonomy and LiDAR scans
SwarmFarm Robotics
Long-running agricultural robot fleet
US wedge
density and scaleShield AI
GPS-denied autonomous flight validation
Saildrone
Months of ocean missions and sensor streams
Gecko Robotics
Inspection robot evidence tied to assets
Carbon Robotics
Crop vision datasets and field failures
Competitive frame
The real competitor is not only another tool.
Roboto and Foxglove are the direct product comparisons. Internal build is the default alternative: object storage, MCAP, scripts, notebooks, search, and replay stitched together by engineers.
DIRECT
Roboto AI
Closest to AI-assisted robotics log analysis and fleet-scale pattern search. Differentiate on mission workflow, stakeholder reports, and account focus.
DIRECT
Foxglove
Strong around MCAP, ROS replay, visualization, and developer adoption. Alloy can own cross-mission intelligence and reporting.
DEFAULT
Internal build
The buyer already has S3, scripts, notebooks, and replay tools. The question is how much engineering time that stack consumes.
First 90 days
Prove repeatability in three passes.
The first AE motion should turn founder narrative into a narrow, testable pipeline: learn the mission-data pain, build named-account density, then package design partners into proof.
01
Days 1 to 15: codify discovery
Interview friendly robotics teams, capture call taxonomy, pressure-test ICP, and turn the demo into a repeatable story.
02
Days 16 to 45: build wedge pipeline
Run focused outbound to ANZ field robotics, US autonomy startups, and maritime, drone, ag, and inspection teams with clear mission-data pain.
03
Days 46 to 90: turn pilots into proof
Convert early conversations into design partners, quantify engineering hours saved, and package the first lighthouse story.