Trajectory raised a $45 million Series A at a $300 million valuation, TechCrunch reported on November 2. Sequoia led the round, joined by Nvidia, Bessemer Venture Partners and Bain Capital Ventures. The company proposes connecting feedback from everyday AI application use to a process that retrains the model over time.
Founders Ronak Malde, Michael Elabd and Arjun Karanam met as Stanford students. Their target users include domain experts who can recognize good work but do not manage machine-learning infrastructure. Trajectory says its system is intended to incorporate that expertise into an ongoing improvement process.
The company calls the approach continual learning. Rather than leaving a model frozen after initial training, it collects feedback on a defined task and uses it in further training cycles. That describes a mechanism, not a promise that every new user response immediately makes a model better.
How feedback becomes training material
In the company’s description, a business connects the system to an application running a model. It collects feedback on the work and uses that information to retrain and improve the model over time. The goal is to reduce the engineering required to manage each cycle manually, from collection to training.
Consider a hypothetical support-ticket classifier. An expert notices a ticket sent to the wrong team and corrects it. That correction could inform future learning. Turning it into improvement, however, requires a definition of a correct correction, representative examples and a way to test whether the update helped.
Feedback can be valuable precisely because it comes from actual work. General examples may miss an organization’s terminology, rules and exceptions. Real usage is not free of errors either: an employee can make a mistaken correction, and users may want conflicting outcomes. Automatic collection does not resolve those disagreements.
This is where domain expertise matters. Experts need not choose every technical parameter to contribute, but they still need to define success. Classification accuracy, policy compliance and writing quality are different objectives. A system can improve at one while deteriorating at another if its training target is poorly specified.
A learning model is not simply a chat that remembers
Retaining information from a previous conversation can help an application respond in context without changing the model itself. Retraining is different: it updates how the model performs a task. Longer memory or access to more documents is not, by itself, evidence of continual weight updates.
The distinction changes what businesses must test. Adding a document to context calls for checking responses informed by that document. Changing a model also requires examining its behavior on other requests. An update that helps training examples may affect unseen cases, including tasks the system already handled well.
Trajectory presents automation as a way to make post-training more accessible. TechCrunch says the platform is becoming publicly available. That does not mean open source, or that every business can connect every model without adaptation. Access terms, supported configurations and operating responsibility are separate from the launch announcement.
Continual does not necessarily mean changing the model in real time after every click. It describes repeated improvement based on new experience. The cadence and route from update to evaluation and deployment depend on implementation. Customers need to know when behavior can change and who may approve it.
What becomes easier, and what work remains
The company wants to reduce some of the technical operation of training. An expert who recognizes an incorrect response should not need a new engineering project every time they provide feedback. If that loop works well, it could bring system users closer to defining the system’s goals.
An accessible process still needs decisions about which feedback to exclude. Sensitive information, unrepresentative cases and unchecked corrections can change the value of training. These are adoption questions, not claims that Trajectory handles them in a particular way or ignores them.
A baseline is necessary too. A higher score needs a named test, a comparison version and defined conditions. Ideally, evaluation includes examples not used for training, so it does not merely measure reproduction of familiar material. Adapting to examples and handling new cases are different achievements.
Rollback matters for the same reason. Improvement is not guaranteed to move in one direction, and problems may emerge only after more usage. An application owner needs to know how to stop an update, compare versions and identify which version performed a particular action at a particular time.
What the funding establishes, and what the product must show
The $45 million round and $300 million valuation establish the reported financial scale, not a performance-test result. Recognizable investors do not demonstrate that every organization will achieve similar improvement or save a fixed amount on training and operation.
The interesting business question is whether expert knowledge can become a repeatable process without losing quality control. An expert may recognize an exception absent from a manual, but that judgment must still become a measurable signal. Expertise and engineering meet here even when an interface hides some technical complexity.
Trajectory is trying to build that connection. For a prospective customer, the test is not whether a product uses the phrase continual learning. It is whether it shows useful change on a defined task over time, with a way to detect regressions. Funding supports development; feedback from real work must demonstrate the value.