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?

We call these case histories Work Episodes. They connect the context, actions, corrections, and observed results of a case, which 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.

Save the selected agent, tool, or workflow with the evaluation behind it, so the next team can understand why it changed.

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 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 more of this understanding can live in the product: shared business records, process definitions, maintained datasets, and reviewed case histories. A new application can then use what the team already knows.

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.