Autonomous software infrastructure

Start with what you want the operation to do

“Help us keep delivery promises. Show the shipments that need attention, assemble the available recovery options, and let the team act.”

You should be able to begin there: an empty workspace, an intention, and access to the relevant data. The first conversation establishes the operation—what a promise means, which systems hold the facts, what the team can change, and when someone must make a judgment.

An agent then has a system to construct. Connect the order system and carrier feeds. Map their records to shipments and customers. Derive the information needed for a decision. Define the process. Build a work surface where people can see the queue, inspect a shipment, and take the next action.

The customer starts with no custom application. The agent starts with Pascal. Data access, shared business objects, tools, work surfaces, and the means to run agents and workflows already belong to the platform. The work is to assemble and adapt those capabilities around this company’s operation.

This is why the infrastructure matters before the first automation. The initial system can be useful while people still do much of the work. It gives that work structure, context, and somewhere for improvements to accumulate.

Connect the data to the decisions it supports

The operation begins outside Pascal. Orders live in an ERP. Customer commitments live in a CRM or an agreement. Carrier events arrive through APIs and streams. Documents and messages explain exceptions. An existing warehouse may already hold much of the history.

Pascal’s data infrastructure brings those sources into a common operating context: discoverable data, maintained pipelines, queryable history, shared identities, and access to the systems where work happens. A useful result can feed an application, an agent, a workflow, or an action in another system.

That is what we mean by an operational lakehouse: a data foundation connected to the decisions and actions of the business. The cycle continues after the query. An action changes the world; its result becomes new data for the next decision.

For an agent, the foundation needs more than tables. It needs a usable world model of the operation: which things exist, how they relate, what state they are in, and what can happen next.

This model gives an agent a way to investigate a problem in business terms. “This shipment is at risk” can lead to its promise, current observations, available actions, affected customer, and the workflow that classified it. A scenario can help examine an alternative before the team chooses to use it.

Operational modeling has strong foundations in systems such as Palantir’s Ontology and object-centric process models. Pascal’s ambition is to make the model equally useful for doing the work and building the software that does it.

When the business changes, the software should follow

A new shipment normally updates the system’s data. A new meaning of “on time” changes how the system should work.

Suppose a customer moves from a delivery date to an appointment window. The new window needs a place in the ontology and data pipeline. Process rules in Compass need to reflect it, Atlas needs to relate it to available routes, and the workflow and application need to guide the team accordingly. An agent needs that context to help prepare a change the team can review.

Those are connected consequences of one business change. The person should be able to describe the new requirement and review its effect on the operation, while the agent carries the implementation work across the affected parts.

The other direction is just as important. An agent might notice that operators repeatedly open several systems before they can decide anything. It can propose a maintained recovery-options dataset, a triage agent, and a view that arrives with the relevant facts already assembled.

Now a software change alters the operation. Gathering context becomes background work. The person begins at the decision. A repeated task becomes an automation. A handoff can disappear.

The organization sets the outcomes and permissions. Changes can be proposed for review, and repeatable changes can be automated within the authority the team grants. The point is to make adaptation an ordinary capability of the system.

Daily work reveals what the next version needs

A work surface is the application the team uses to run its operation: a queue, a case workspace, a planning board, a decision screen. Because it is built on Pascal, it can share the same data, business objects, actions, and agents as the rest of the system.

That makes a request such as “show me the last viable recovery option” richer than a layout change. It may require a new calculation, a new source, and a different order of work. The surface and the capabilities beneath it can be changed together.

Daily use also reveals what the initial design missed. Which information did people search for? Where did they override a recommendation? Which exceptions kept returning? Which actions were repeated? Which decisions took time because the necessary context was scattered?

Work Episodes give that experience a useful shape: a record of the case, relevant context, actions, corrections, and observed results. A case may span several sessions. Its history can bring together what the person did in a work surface, what an agent attempted, and what the surrounding process recorded.

The useful lesson is rarely “repeat these clicks.” It might be “this field is missing,” “these two tasks can be separated,” or “we can obtain the answer directly from a better source.” Research on robotic process mining makes the distinction clear: finding repeated interactions and reconstructing an executable routine are different steps.

From 1,000 episodes to a better way of working

Imagine the delivery team has accumulated enough sessions and Work Episodes to reconstruct 1,000 comparable, completed cases. Each case includes what was available when the decision was made, the work performed, relevant corrections, and the eventual result.

Those cases are useful material for building an agent. An illustrative split is 700 cases for development and 300 held back for evaluation. The development cases help an agent understand the task, build a candidate, diagnose failures, and compare alternative approaches. The held-out cases test the selected candidate on work it has not been allowed to optimize against.

The agent doing the building has several things it can change. Instructions and examples. Which available tools to use. Where to look for data. How to split a complex task. When to call a specialist. Whether a repeated calculation belongs in a pipeline. The candidate agent becomes an executable proposal for how the operation could work.

This direction has concrete research behind it. Automated Design of Agentic Systems demonstrates a meta-agent programming and evaluating other agents. GEPA uses execution traces and feedback to propose and test improvements to prompts. These mechanisms improve the software around a model; they do not require training new foundation-model weights.

Compare the candidate with the current procedure on the same held-out cases. Judge the job: correct decisions, coverage of exceptions, time, cost, and the help required from people. The candidate need not imitate every historical step. A faster procedure can be better precisely because it removes a workaround that people previously needed.

The split needs care. Keep related cases together, and use time separation when testing future work. Do not give the candidate facts that only became known afterward. Keep candidate selection within development; repeatedly adapting to the held-out results turns that set into more development data. Fresh work supplies the next independent test.

The result is a cycle with something durable at its center: a better agent, a useful tool, a new workflow, or a maintained source of data. Future tasks can use that improvement without rediscovering it.

Turn a useful procedure into repeatable work

The first agent might investigate each shipment from scratch. It searches for the order, looks up carrier events, interprets the agreement, compares recovery options, and drafts a recommendation.

After enough cases, it may identify a better structure. Retrieve independent facts in parallel. Use a carrier event feed instead of repeated portal lookups. Separate factual triage from commercial judgment. Calculate the recovery window once and keep it current. Ask a person only when the case exceeds the agreed rules.

Research such as AFlow treats agentic workflow design as a search over executable steps and their connections. That makes the procedure itself something to improve. A useful change can reorganize the work, as well as improve an individual response.

An agentic automation can combine both forms. A new carrier event starts the workflow. A pipeline supplies current context. A function checks a well-defined condition. An agent investigates an ambiguous exception. An approved action updates the external system, and the result returns to the case.

The automation can evolve too. New cases reveal a missing rule. A better data source changes the investigation. A recurring agent decision becomes a tested function. A change in customer policy brings a person back into a step that was previously automatic.

The same principle applies beneath the application. If agents keep repeating an expensive join, Pascal’s data infrastructure is part of the improvement opportunity: maintain the result, improve the pipeline, or choose a more suitable data path. Use-driven optimization already has bounded examples in Dremio’s Autonomous Reflections, which observe query traffic and manage accelerations. The broader opportunity is to connect such improvements to the operation that benefits from them.

Build knowledge into the product

A forward-deployed engineer often supplies the connection between a company’s operation and its software. They understand the systems, reconcile the data, learn the exceptions, build the application, and return when the business changes.

Pascal’s thesis is that this connection should live in the product. Business meaning belongs in the ontology. Process knowledge belongs in the operating model. Repeated data work belongs in pipelines. Useful decisions and corrections belong in Work Episodes and evaluations. The application, agents, and workflows should be able to build on all of them.

That is the reason to build an operational system on Pascal. An agent works within an environment that already connects these capabilities. It can use the existing customer identity, permitted action, process definition, or maintained dataset when creating the next piece of software. Each new requirement has less foundation to rebuild.

The goal is to reduce the need for a permanent embedded engineering team to translate every business change into custom software. Teams still need to define the outcome, connect the right systems, review the implementation, and judge the result. Pascal aims to make that work reusable, so the next change starts from what the company already understands.

The payoff grows beyond the first operation. Customer escalation can reuse what delivery recovery already knows about orders and promises. Capacity planning can build on the same routes, resources, and outcomes. A new work surface can use the same agents and actions. Improvements become available to more of the company.

Build the first useful system. Use it. Let its history reveal the next agent, the next automation, and the next simplification. As the company changes, the system has both the context and the means to change with it.