Business workflows that keep their place.

A business process needs memory beyond a single request.

In brief

A customer places an order. The payment goes through. The connection drops before the confirmation comes back. Meanwhile, the warehouse is waiting for instructions and the customer is wondering whether to click “Buy” again. Somewhere, a support team is about to become a distributed transaction coordinator—with a spreadsheet.

These situations happen between otherwise well-built systems. Each service can correctly handle its own records while the business process needs an answer to a larger question: what has happened, what still needs to happen, and what is safe to try again?

Vectis is a platform for building services that keep track of those answers. Its workflow model records a business change together with the work that change requires, arranges delivery, and gives repeated attempts a consistent identity. When the receiving system recognises that identity, another attempt means “finish this same operation”, rather than “create another one”. A worker can also save its progress alongside the work, so the next attempt can pick up with knowledge of what the previous one accomplished.

That is the basis of an exactly-once business outcome: several technical attempts can still produce one order, one reservation, or one payment. The process has a memory that survives a restart and a reliable way to carry work from one system to the next.

Applications describe their business rules in Lua, a small programming language embedded in Vectis. Underneath it, C libraries provide the web server, API clients, data handling, state storage, transaction coordination, and background work. The same foundation can support an integration service, an API, a web application, a WebDAV file server, or a backend for a dashboard. AI agents can participate through tools and stored workflow state. Industrial equipment, files, and even spoken reports can feed the same business process through the bundled connectivity and local speech recognition capabilities.

The reason to use Vectis is practical: an architect working with AI agents, a developer, or a larger team can start with the difficult reliability machinery already brought together. Lua keeps business logic compact and readable for people and gives coding agents concise operations to use at machine speed. The transaction, retry, and recovery engineering becomes a shared investment that benefits every application built on it. Development starts with the business change and its next action, using the supplied transaction and delivery model. More of the work goes directly into the business solution.

Project repositoryVectis on GitHub↗ State and workflow foundationliblockdc on GitHub↗

One runtime can meet the business wherever the work begins.

What it can become

Vectis can host an operational service at the point where a business process meets the world: accept an order through an API, receive a production event from equipment, collect a partner file, transcribe an inspection note, call a payment or logistics service, and keep the decision and its next actions durable through restarts and retries. A website, dashboard, file service, or agent tool can be a surface on that same workflow foundation, rather than a separate class of application.

Websites and web applications. The embedded Kore server can serve static content, application routes, forms, and downloads over HTTPS. Authentication and certificate handling support internal tools, customer portals, and content sites. Lua defines the application behaviour, and the service can be packaged with its scripts and web assets.

File servers and document exchange. Vectis can run as a WebDAV file server, giving compatible clients authenticated access to files and folders. Uses include a shared document area, a partner upload service, or a publishing setup where authorised editors manage files through WebDAV and readers access them through the website. WebDAV client APIs also let applications work with files hosted elsewhere.

API servers and data adapters. A service can expose REST or RPC operations, combine responses from existing APIs, and translate between data formats. LoneJSON supplies efficient typed JSON parsing and serialisation: it maps incoming data to defined records and writes those records into outgoing API payloads. XML and CSV/TSV support allow the same service to bridge partner APIs, data exports, and existing enterprise systems.

Dashboards and backends for user interfaces. A Vectis application can gather information from equipment, remote services, and stored records, then provide it to a web interface. This is a backend-for-frontend, or BFF. Examples include a production overview, a partner-status page, or an operations console. The application defines the dashboard and its presentation; Vectis supplies web serving, connectivity, and data processing.

Equipment gateways and operational automation. OPC UA, MQTT publishing, HTTP, SSH, and file-transfer APIs let applications connect industrial systems with business software. A service could expose machine readings through an API, publish selected updates to a broker, collect diagnostic files, or execute an authorised maintenance command on a remote system.

Speech and audio services. An application can capture or read audio, transcribe it locally with Whisper, and return text through an API or a web interface. Examples include a transcription service for uploaded recordings, spoken inspection notes, and push-to-talk input for an operational tool. Local CPU execution makes this useful on systems with no dedicated GPU.

AI agents and tool servers. CAI supplies an OpenAI Responses API C client, an agent runtime, and Model Context Protocol (MCP) client/server capabilities. MCP gives agents a common way to discover and call tools. Applications can offer an assistant, run an agent in the background, or expose existing business functions as tools for other agents. Vectis also hosts a terminal coding-agent experience through CAI, with libmdf rendering Markdown and Softline providing terminal interaction.

Durable business workflows. Orders, account provisioning, claims, and logistics are examples where several systems must cooperate over time. A Vectis application can record the business decision, arrange subsequent work, and preserve progress across retries. Work requiring attention can be retained for inspection and later replay in a dead-letter store: a place for work that has exhausted retries or needs intervention.

These uses fit together naturally. A file server can offer transcription of uploaded recordings. An equipment gateway can supply a dashboard and publish updates. An API service can expose the same operations as agent tools. When an action starts a longer business process, the durable workflow foundation is available in the same environment.

The failures that matter happen in the handoff.

Between systems

Consider an order that passes through sales, inventory, payment, delivery, and a partner's reporting system. Each service has its own data and its own view of progress. Some steps happen immediately; others may wait for a remote service to return or for a business condition to be met.

The difficult failures happen between steps. A service saves an order and restarts before requesting delivery. A partner completes a booking, but its response is lost. Two workers receive the same message. A failed job is replayed after an operator has corrected the underlying problem.

These cases require decisions about the whole process. Should the booking request be sent again? Has the previous worker saved useful progress? Does a replayed message represent new work or work already completed? If a later step cannot proceed, what should happen to the earlier ones?

An architect directing AI agents and an enterprise development team face the same architectural questions. Both work within budgets, delivery schedules, and the time required to exercise real systems. Building and maintaining a complete recovery model for every integration consumes design attention and repeated test cycles. Vectis concentrates that effort in a reusable runtime, giving applications a consistent way to handle state, follow-up work, and recovery.

Make the change and its next action one decision.

One decision

A service's state is its stored knowledge: an order's status, a reservation, or the progress of a job. Durable state survives the process that wrote it. A transaction lets related changes be saved as one all-or-nothing decision.

Suppose a service saves an order and then sends a message to the warehouse. There are two separate writes. If the service stops between them, the order exists but the warehouse never hears about it. Sending the message first reverses the risk: the warehouse may act on an order that was never saved.

The transactional outbox solves this by saving the order and the instruction to contact the warehouse in one transaction. Either both records are committed, or neither is. A background dispatcher picks up the committed instruction and arranges its delivery. If the service restarts before delivery, the instruction is still there.

The outbox therefore turns “remember to send this” into a durable part of the business decision. AWS describes this as solving the dual-write problem. Microsoft's .NET microservices guidance likewise treats reliable publication alongside a state change as an architectural responsibility.

Delivery can involve several attempts. Vectis carries a stable identifier for the intended action—called an effect—so an integration can use the receiving system's rules for recognising repeated requests. This is idempotency: repeating the same operation has the same business result as performing it once. Payment APIs such as Stripe use idempotency keys for this purpose.

On the receiving side, a transactional inbox records that a message has been handled together with the state change it caused. A repeated message can then be recognised without repeating the business action. Together, inboxes, outboxes, and stable identities support reliable chains of services.

The transactional workflow links transported work to the decision that created it. Recovery can use that record to find pending actions, and retries retain the identity of the original operation.

Some records must agree before work can move.

What must agree

XA coordinates an all-or-nothing transaction across participating resources. It lets participating stores agree to commit or roll back related changes, including when they are managed by separate systems.

In Vectis's Lockd/liblockdc foundation, this coordination allows business state, workflow receipts, and outbox records to participate in the same transaction. Implicit XA means that related operations can be brought into that transaction through the normal state operations, with coordination handled underneath.

For example, accepting an order may require updating its business record, recording acceptance of the customer's request, and recording the instruction for the warehouse. Those records should describe one decision. After an interruption, recovery follows the transaction's durable decision so that the records remain consistent.

XA and the outbox have complementary roles. XA coordinates changes within the participating transaction. The outbox carries committed work onward to systems such as a payment gateway or a partner API. At that boundary, the integration uses stable identifiers and the recipient's rules for safely repeating work.

A longer business process can use many such transactions. Application rules decide what to do when circumstances change—for example, releasing a stock reservation when a payment is declined. Vectis gives those decisions and their follow-up actions a durable foundation.

The next attempt should inherit what the first one learned.

A retry that remembers

Through Lockd/liblockdc, work can arrive with an associated state object. A queue consumer or outbox handler can read and save progress associated with the item it is processing.

For example, an integration might validate an address, obtain a partner reference, prepare a document, and then wait for a delivery window. The handler can persist those facts even when it defers the item or returns it for another attempt. The next consumer reads the saved progress and makes an informed decision about what to do next.

Successfully persisted progress can survive a later failure in the attempt. The job remains pending, and the next consumer can read what has already been learned or completed.

Lockd supplies remote state and coordination; Pouch provides local storage through liblockdc. Vectis brings that foundation into the same application environment as its web routes and integration clients. Applications can use durable progress as part of ordinary business logic.

Keep the business rules clear; put the machinery underneath.

Rules above. Runtime below.

Vectis has two main forms: a C SDK for native applications and a runtime that executes Lua applications. Lua provides a compact way to express business rules, connect components, and define how a service responds to requests or background work.

This division is familiar in other products. Microsoft Business Central uses AL to build applications within its business platform. Roblox creators use Luau, a language derived from Lua, to define behaviour on the Roblox platform. In both cases, application authors work through a language and an API while the platform supplies the underlying machinery.

Lua is also used to extend infrastructure and tools: NGINX integrates Lua with its event-processing model, and Pandoc embeds Lua for document filters. The approach lets a substantial native system expose a small, expressive programming surface.

Lua applications use ordinary functions, modules, and data structures, with code kept in version control and covered by application tests. Native components handle networking, storage, data conversion, and transaction coordination, keeping the Lua code close to the business task.

Lua's small language and Vectis's purpose-built interface make that code easy for a person to read, write, and review. The same concise operations give AI coding agents a direct way to implement a request. An architect can inspect the business rules while agents produce and test the surrounding application at machine speed. A team can use the same approach collaboratively.

C# offers a broad language and application ecosystem. Vectis's Lua facade—the interface through which Lua calls the underlying libraries—concentrates on its supported service patterns. Each operation provides substantial behaviour: recording work, retaining state, or completing a transaction uses an interface with defined rules. That keeps application code compact.

That straightforward surface rests on substantial runtime engineering. Kore, the embedded web server, uses an event-driven model with separate worker processes. Background work also involves threads. Each Lua execution environment has clear ownership, and communication between processes uses explicit channels. Vectis coordinates these boundaries so that web requests, background work, and durable state can operate together.

A workflow begins wherever the working world speaks.

The working world

In a factory, warehouse, service desk, or customer site, a business process can begin with a machine reading, a file delivery, or a spoken report. Vectis bundles APIs for these inputs and for the systems that receive the result.

OPC UA connects industrial equipment and software. Applications can read and write equipment data, subscribe to changes and events, and invoke exposed methods. The bundled surface also supports building OPC UA servers. A Vectis application could follow a production counter, associate readings with a job, or turn an equipment event into a maintenance case. It can expose selected information to both industrial clients and a business API.

MQTT publishing connects a workflow to device and messaging environments. A service can publish a status update or a JSON message to a broker as part of an integration. For example, a warehouse application could publish that a job is ready for collection. Vectis's durable workflow can retain the intent to publish, while the receiving application uses the message identity to recognise repeated delivery.

libcurl provides the network-transfer foundation. The bundled libcurl APIs support HTTP/HTTPS calls, uploads, downloads, and other supported transfer protocols. JSON helpers connect API traffic to LoneJSON's data handling. An application can fetch a supplier catalogue, call a partner API, upload a document, or download a large data file through the same service environment.

SSH, SFTP, and SCP reach systems that work through commands and files. SSH allows an application to execute an authorised remote command; SFTP and SCP provide secure file transfer, with SFTP also offering remote file operations. These are useful where a partner exchanges nightly files or an operational system exposes a command interface. CSV, XML, and JSON support then help turn the incoming information into business records. SMTP supplies email delivery, and WebDAV provides another way to serve and exchange files.

Audio and Whisper bring spoken information into the workflow. Vectis includes audio capture and playback, decoding, and mechanisms for separating speech into segments, including voice activation and push-to-talk. Its Whisper-based transcription can use a local model and run on a CPU. With the model available locally, transcription can take place on site without sending the recording to a remote speech service. An application can turn a recorded inspection, maintenance note, or spoken report into text for review and further processing.

Consider a maintenance application assembled from these capabilities. An OPC UA subscription reports an equipment condition. A technician records a spoken observation, which Whisper transcribes locally. The application brings the machine data and reviewed note into a work order, saves the decision, and records the required handoff to a maintenance system. It could send supporting files through SFTP, publish status through MQTT, and make progress visible in a web interface. If the maintenance system is temporarily unavailable, the recorded work and saved progress remain available for another attempt.

The application defines the relationship between these steps. Web serving, industrial protocols, file transfer, speech recognition, and transactions each contribute to the same business process. Vectis provides the environment in which they can operate together.

The value of a system lives in more than its language.

What survives migration

In its account of an ING Bank migration, SoftwareMining describes converting approximately 1.5 million lines of COBOL to Java and deploying the application on Linux in 2022. The supplier reports testing more than two billion transactions side by side, checking concurrent sessions, retaining messaging continuity, and preserving nightly batch processing windows. CICS-compatible runtime libraries and messaging integration supported the converted code. The migration combined language conversion with the preservation of an entire operating model. ING migration case study

Academic research gives another concrete view of that engineering cost. Rodriguez and colleagues studied a government agency's migration of 32 CICS/COBOL transactions to web services. A first approach wrapped the existing transactions in five days with one developer. The resulting interfaces were difficult for application developers to understand and reuse. A second approach redesigned the services and reimplemented the functionality in .NET, taking 13 months with eight developers and three specialists. The researchers describe repeated comparisons against the original system to establish equivalent behaviour. The two approaches delivered different interface quality and architectural scope: much of the added effort went into designing the service boundaries and rebuilding the implementation. The SOA Frontier: Experiences with Three Migration Approaches

These cases show where an enterprise system's value accumulates: in its business rules, the runtime supporting them, and the evidence that the whole system behaves as intended. Vectis brings that principle to new services. Transaction coordination, dispatch, saved progress, and recovery are shared components with their own tests. Each application inherits that work and adds the business behaviour specific to its task.

Choose the foundation that fits the central engineering problem.

Why Vectis

Choose Vectis when the service's central job is to connect systems, keep durable business state, and reliably carry a decision into subsequent actions. It supplies that architecture as a coherent programming model. Development can start by defining the operation, its state changes, and the handlers that perform the follow-up work.

With a general-purpose .NET or Java application platform, the architect, team, or coding agent establishes the workflow architecture as part of the project. That involves selecting persistence and messaging components, defining transaction boundaries, connecting publication to business-state changes, configuring delivery and recovery, and ensuring that relevant application paths use that arrangement. Established libraries supply substantial parts of this work. Their selection and composition become part of the application's architecture.

For example, MassTransit's Entity Framework outbox supplies persistence and a delivery service. The application integrates its outbox entities into the database model, selects the database provider, and configures the relevant bus and consumer paths. NServiceBus supplies an outbox and a Transactional Session for operations initiated outside message handlers. These are concrete, reusable implementations that a .NET team can choose and integrate. MassTransit outbox configuration, NServiceBus transactional sessions

JBoss EAP supplies a transaction manager and XA recovery for participating resources such as databases and messaging systems. Application architecture includes configuring those resources and defining the operations that use them. External HTTP calls, files, and partner actions still need an application-level delivery model around that transaction boundary. JBoss transaction and recovery model

Vectis supplies a defined combination: the state and workflow foundation is liblockdc with Lockd or Pouch, the business interface is available in Lua, and web serving, background work, and integration clients share the runtime. An outbox is a workflow operation the developer can use immediately. The supporting libraries manage dispatch, temporary ownership of work, retries, and recovery.

For an order-to-partner integration, that changes where development effort goes:

Teams with an established .NET messaging platform already benefit from a similar investment in standardisation. Vectis packages its particular combination—stateful work, transactional delivery, native protocol clients, and Lua—in the platform itself. A new project can adopt that combination directly.

Less newly assembled infrastructure means a shorter feedback loop.

A shorter route

An instruction such as “accept an order and notify the warehouse” describes the business intention. The implementation still needs to choose what happens if saving succeeds and notification fails. On a general application platform, the project architecture or the coding agent must choose and integrate a reliable delivery model, such as a transactional outbox. If the design saves and sends in separate steps, ordinary success-path tests can pass while the gap remains.

Vectis makes the durable pattern visible at the point of implementation. The executable carries documentation and public Lua facade source matching that build, available through vectis -a docs and vectis -a source. An agent can inspect the workflow operations, ownership rules, and examples from the environment it is programming. The task “save this change and arrange that action” has a directly discoverable implementation in the supplied API. Vectis's embedded documentation and source

This makes the outbox a natural design recommendation for an agent reading Vectis's interfaces. The developer can ask for the business operation, and the local documentation gives the agent a ready path to durable delivery. The architecture is easier to discover, easier to use consistently, and easier to recognise during review.

An AI agent can also configure MassTransit, generate C# handlers, and assemble the surrounding application quickly. Elapsed development time includes what happens next: restore dependencies, build, start a database and broker, apply schemas, exercise the integration, interrupt delivery, restart a worker, and check the result. Each correction may require another cycle through those systems. Code generation can accelerate while those operations still take their own time.

Vectis reduces how much newly assembled infrastructure enters that loop. The application uses the existing transaction, dispatch, and recovery implementation through a compact Lua interface. Infrastructure testing accumulates in the shared components; application testing focuses on business rules, partner contracts, and the application's use of those components. Fewer new connections between libraries mean fewer application-specific interactions to diagnose and repair.

This changes the economics of an AI-driven development session. A smaller application surface gives the agent less code to generate and the architect less code to review. Reusing the runtime removes categories of infrastructure implementation from the task. Together, those reductions shorten the route from a business request to a working integration.

Research into AI-assisted COBOL-to-Java translation illustrates the same need for executable feedback. In their FSE 2025 paper, Hans and colleagues describe generating tests from COBOL behaviour, turning them into Java tests, and using discrepancies to identify translation faults and improve the results. The engineering loop includes generation, execution, diagnosis, and repair. Automated Testing of COBOL to Java Transformation

Repeated engineering belongs in the foundation, not every service.

Shared engineering

The Vectis ecosystem is being developed through an AI-native engineering process that combines human architectural direction with sustained automated implementation, review, testing, and refinement. Across Vectis and its supporting components, this represents roughly a year of continuous investment, including work that runs overnight.

That changes how much attention can be given to infrastructure. Failure paths, resource ownership, restart behaviour, and recovery can receive repeated implementation and review cycles. Each useful finding can become a regression test that protects later applications.

The source shows concrete examples of this approach. liblockdc contains tests for state and outbox transactions, duplicate inbox delivery, retry scheduling, dead-letter replay, startup recovery, and state-handle behaviour after queue acknowledgement. Vectis adds tests around the composition of its service runtime, Lua interfaces, and packaged applications. The tests make expectations about difficult cases explicit and repeatable.

The time-consuming investment is in making transaction decisions, process and thread ownership, persistence, dispatch, and recovery work together. As that foundation stabilises, an architect with AI agents or an enterprise team can reuse it across applications. Each project adds its own business rules, interfaces, and partner contracts through small Lua programs, drawing on engineering that would be costly to reproduce independently.

Common contracts let focused services work as a larger whole.

An estate, not a monolith

An estate is a collection of services operated for a business or customer. Consider an architect directing several agents to build a supplier gateway, a document service, an equipment adapter, and a customer-facing API. With Vectis, each agent works against the same runtime contracts and embedded documentation. The applications differ in their business rules and external connections, while sharing the mechanisms for state, delivery, and recovery.

That common structure supports work across several estates at once. A fix in a shared component can be verified centrally and adopted through controlled runtime upgrades. A workflow convention established in one application can be reused in another. Reviews can focus on the new business behaviour and its integration boundaries. Small application codebases make that repetition easier for both people and coding agents to follow.

The resulting economy is in the amount of software an architect or team must own per service: fewer bespoke workers, persistence adapters, recovery routines, and framework connections. Vectis's native runtime and embedded Lua also keep deployment centred on a common executable and its application code. This is the opportunity at estate scale: invest deeply in the foundation, then reuse it across many independently useful services.

The foundation can grow without changing the model.

Room to grow

The direction is to extend that foundation with PostgreSQL and SQLite connectivity and messaging clients such as RabbitMQ/AMQP. PostgreSQL transaction participation through a liblockdc XA driver would allow relational data and Lockd state to share a coordinated decision, with an outbox carrying the resulting work onward. Provider-specific messaging adapters can package the delivery and duplicate-handling conventions for each integration.

Planned support for plugins loaded as native shared libraries provides another extension path, including drivers for enterprise databases such as IBM Db2 and MariaDB. This allows connectivity to grow with the needs of applications while keeping the workflow model consistent.

Another natural extension would be QR and barcode recognition from JPEG images or frames in an MJPEG camera stream. A warehouse application could associate a scanned package with an order; a maintenance application could identify equipment before attaching a spoken report. This is a prospective addition that follows the same principle: turn information from the working environment into a reliable business action.

The ambition is to connect hundreds of focused Lua applications into reliable business processes. Each application contributes its own rules and expertise; the shared foundation preserves the decisions, progress, and handoffs that make the whole process work. An architect with AI agents or a larger team can carry that shared engineering investment into each new application and each new estate.