Workspaces: Building a Headless Company OS for API-first Processes and AI Agent Workflows
Many business systems were historically built around user interfaces.
- CRM? UI.
- ERP? UI.
- Document management? UI.
- Commerce? UI.
- Reporting? UI.
That works as long as humans manually execute every process step.
But modern companies increasingly need something else: systems that can be automated, integrated, and controlled by other systems.
This is one of the reasons we are building Workspaces.
Workspaces is our approach to a headless Company OS with an ERP core, web administration, and API-based operation for business processes. The platform brings together CRM, commerce, PIM, documents, workflows, tasks, compliance, reporting, chat, newsletters, AI-adjacent features, and task streams in one shared multi-tenant system.
But this article is not meant to sound like everything is already perfect.
It is not.
We are not perfect either. But we are working on it.
And that is actually an important part of the story.
Workspaces is not just a product name for us. It is a direction. A journey. A long-term attempt to make operational business software more programmable, more open, and more useful for automation.
The goal is not simply to build another ERP with a nice web interface.
The goal is to build a platform where humans, systems, integrations, and eventually AI agents can work with business processes through stable contracts.
Why We Started Thinking About This
If you have ever integrated business software, you probably know the problem.
Many systems have an API, but the API often feels like an afterthought.
The UI is the real product.
The API is something added later.
The documentation is incomplete.
The data model is hard to understand.
Permissions are unclear.
Workflows are hidden inside UI actions.
Automation requires too much custom glue code.
For simple integrations, this might still work.
For serious automation, it becomes painful.
And when AI agents enter the picture, the problem becomes even more obvious.
An AI agent does not need a beautiful dashboard. It needs reliable answers to very practical questions:
- Which actions are available?
- Which data may I access?
- Which parameters are required?
- Which workflow can I start?
- How do I check the current status?
- What happens if something fails?
- In which tenant and permission context am I operating?
A system that was designed only from a UI perspective usually cannot answer these questions cleanly.
That is the gap we are trying to close with Workspaces.
The Basic Idea Behind Workspaces
Workspaces is designed as a headless-capable business platform.
The web administration interface is still important. People need good tools. Teams need dashboards, forms, lists, reports, tasks, and workflows.
But the UI should not be the only way to operate the system.
Core functions should also be accessible through APIs. Processes should be controllable by external systems. Clients should be able to discover what is available. Authentication and permissions should be part of the platform contract.
In simplified form, the idea looks like this:
External systems
AI agents
Integrations
Automations
Internal web administration
│
▼
/api/v1
│
▼
Workspaces Company OS
CRM · ERP · Commerce · PIM · Documents · Workflows · Tasks · Reporting · Compliance
The important part is this:
API access is not supposed to be a side feature. It is supposed to be part of the foundation.
This is something we are actively working toward.
Some parts are already there. Some parts are still evolving. Some things will certainly change as we learn from real use cases.
But the direction is clear: business software should become more programmable.
API-first Is More Than “We Have an API”
A lot of software products say they are API-first.
But in practice, “API-first” can mean very different things.
For us, it means that the API should not merely expose database objects. It should represent useful business capabilities.
Not only:
POST /contacts
PATCH /orders/123
GET /documents/456
But also:
Start a customer onboarding workflow.
Create a task in the correct business context.
Attach a document to an entity.
Check the status of an automation.
Expose available capabilities to a client.
Respect tenant and permission boundaries.
This distinction matters.
Business software is not only about data. It is about processes.
And processes need more than CRUD.
Discovery-first Instead of Hardcoded Assumptions
One principle we care about is discovery.
Instead of forcing clients to hardcode every path, every feature, and every entry point, we want Workspaces to expose available capabilities at runtime.
A simplified example could look like this:
GET /api/v1/capabilities
The response could describe which capabilities are available in the current context:
{
"tenant": "example-company",
"capabilities": [
{
"name": "crm",
"entrypoint": "/api/v1/crm",
"actions": ["read_contacts", "create_contact", "update_contact"]
},
{
"name": "documents",
"entrypoint": "/api/v1/documents",
"actions": ["upload", "classify", "link_to_entity"]
},
{
"name": "workflows",
"entrypoint": "/api/v1/workflows",
"actions": ["start", "inspect", "cancel"]
}
]
}
This is useful for traditional clients.
It is even more useful for dynamic clients and AI agent workflows.
Instead of assuming:
I hope this endpoint exists.
A client can ask:
What can I do here?
Which capabilities are available?
Which actions are allowed?
Where do I start?
That is the kind of interaction model we want.
We are not fully done with this vision. But we believe this is the right direction.
Why OpenAPI-like Contracts Matter
For developers, an API is only truly useful when it is documented, consistent, and machine-readable.
That is why Workspaces moves toward OpenAPI-like contracts, structured metadata, and field-level descriptions.
This matters for:
- SDK generation
- API clients
- validation
- tests
- external integrations
- AI agent tooling
- documentation
- field-level access control
- privacy-aware data handling
In business software, a JSON response alone is not enough.
A client should be able to understand which fields are readable, writable, required, sensitive, or restricted.
A simplified example:
{
"resource": "contact",
"fields": {
"id": {
"type": "string",
"readOnly": true
},
"email": {
"type": "string",
"privacy": "personal_data",
"required": true
},
"customerNumber": {
"type": "string",
"readOnly": true
},
"internalNote": {
"type": "string",
"visibility": "restricted"
}
}
}
For normal software clients, this is helpful.
For AI agents, it becomes essential.
An agent should not simply read, interpret, or modify everything it sees. It needs boundaries. It needs contracts. It needs to know what is allowed.
This is one of the reasons we think API design, metadata, and privacy-aware field contracts are becoming more important, not less.
Headless Authentication and API Key Operation
If business processes should be automated, a classic browser login is not enough.
External systems, services, and agents need ways to authenticate without a human clicking through a web interface.
That is why Workspaces supports and continues to evolve around headless login flows and API key operation.
But authentication alone is not enough.
Every API call exists in a business context:
Who is calling?
For which tenant?
With which permissions?
For which capability?
For which purpose?
This is especially important in a multi-tenant system.
An AI agent that analyzes documents, creates tasks, or updates CRM data must not operate outside its allowed context.
Permissions, tenant context, and authentication should not be bolted on later. They should be part of the platform contract from the beginning.
This is a difficult area, and we are still learning.
But it is also one of the most important areas.
Because automation without clear boundaries is not progress. It is risk.
Workflows Instead of Isolated API Calls
Many APIs are built around isolated operations.
Create this.
Update that.
Delete something else.
That is necessary, but it is not enough for real business processes.
A typical process often looks more like this:
- A new lead comes in.
- The company and contact data are checked.
- A CRM record is created or updated.
- A document is attached.
- A compliance rule is evaluated.
- A task is created.
- A person or team gets assigned.
- A reporting event is written.
- The process continues depending on the result.
If this logic lives only in external scripts, middleware, or cron jobs, the process becomes fragmented.
The data is in one place.
The workflow is somewhere else.
The business rules are hidden in custom code.
The status is hard to inspect.
That is exactly what we want to improve.
Workspaces is designed to support workflows and task streams so that integrations and agents can work with processes, not just records.
A simplified workflow start could look like this:
POST /api/v1/workflows/start
{
"workflow": "new_customer_onboarding",
"input": {
"companyName": "Example GmbH",
"email": "info@example.com",
"source": "website"
}
}
The response could return the current process state:
{
"workflowRunId": "wf_123456",
"status": "running",
"next": {
"type": "task",
"assignedTo": "sales",
"label": "Review customer data"
}
}
This turns the API into more than a data pipe.
It becomes a process interface.
Why This Matters for AI Agents
AI agents are often described as chatbots.
But for business software, the more interesting question is not whether an agent can chat.
The interesting question is:
Can an agent safely perform useful work inside real business processes?
To do that, the agent needs access to tools, data, workflows, and status information.
But that access must be controlled, traceable, and understandable.
Workspaces is being built with this direction in mind.
An agent should be able to:
- discover available capabilities
- authenticate headlessly
- operate in a tenant context
- understand allowed actions
- call APIs with documented parameters
- start workflows
- create tasks
- check process state
- write results back into the business context
This does not mean that every process should be fully autonomous.
It also does not mean that an AI agent should replace human decision-making everywhere.
In many cases, the best model is a hybrid one:
Agent prepares.
System validates.
Human approves.
Workflow continues.
That is a much more realistic and useful approach than pretending that everything should be automated immediately.
A Possible Agent Scenario
Imagine a company receives an inquiry through a web form:
"We are interested in product X and would like to receive an offer."
An AI-assisted workflow in Workspaces could look like this:
- Receive the inquiry.
- Check whether the company already exists.
- Create or update the CRM contact.
- Fetch product information from the PIM.
- Link relevant documents or price lists.
- Check compliance or internal rules.
- Create a task for the sales team.
- Write the current status into the task stream.
- Prepare a draft response.
- Let a human review and send it.
The agent does not need to rebuild the CRM, ERP, PIM, document management, and task system.
It uses Workspaces as the operational control center.
AI agent
│
├─ queries available capabilities
├─ authenticates headlessly
├─ reads permitted CRM and PIM data
├─ starts workflows
├─ creates tasks
├─ checks status
└─ writes results into the process context
This is the kind of architecture we believe will become increasingly important.
Not because AI magically solves every business problem.
But because AI becomes much more useful when it can operate through stable, well-defined, permission-aware interfaces.
The Hard Part: Business Software Is Messy
One thing we have learned again and again: business software is messy.
Every company has different processes.
Every team has exceptions.
Every workflow has edge cases.
Every integration reveals another detail.
Every automation needs guardrails.
That is why we do not want to present Workspaces as if everything is finished and flawless.
It is not.
We are building it step by step.
We are improving the APIs.
We are refining the capability model.
We are working on better metadata.
We are improving workflow handling.
We are learning where automation helps and where humans must stay in control.
And yes, sometimes we discover that something we built needs to be changed.
That is part of the journey.
The important thing is the direction:
We want to make operational business software programmable, discoverable, automatable, and ready for a future where humans, systems, and AI agents work together.
Why a Shared Data and Process Framework Matters
Many companies use a separate tool for every area:
- CRM for contacts
- shop system for commerce
- PIM for product data
- DMS for documents
- task tool for assignments
- newsletter tool for communication
- reporting system for analytics
- compliance tool for rules
That can work.
But it creates integration cost.
Every automation has to connect multiple systems.
Every agent needs several APIs.
Every process must synchronize context across tools.
Every exception creates another piece of glue code.
Workspaces follows a different approach.
Operational domains should exist in one shared multi-tenant system, or at least in a shared process and API framework.
That does not mean every company has to treat everything as one monolith.
But it does mean that processes can be modeled more consistently across domain boundaries.
For developers, this is helpful because less logic disappears into middleware, cron jobs, and one-off scripts.
What Developers Might Find Interesting
For developers, Workspaces becomes especially interesting when business software is not only used, but integrated, extended, automated, and programmed.
Some of the technical ideas behind it are:
- API-first architecture
- headless operation
- discovery endpoints
- capability-based access
- OpenAPI-like contracts
- machine-readable metadata
- privacy-aware field contracts
- multi-tenancy
- permission and authentication context
- workflow start and status inspection
- task stream integration
- operational domains in one shared system
This is a different perspective on business software.
Not:
Here is an ERP with a user interface.
But:
Here is an operational backend that humans, systems, and agents can use through stable contracts.
That is what we are working toward with Workspaces.
Conclusion
Workspaces is our attempt to build an API-first, headless-capable business platform for operational processes.
It combines an ERP core, CRM, commerce, PIM, documents, workflows, tasks, compliance, reporting, communication, and additional functions in one shared multi-tenant system.
But more importantly, Workspaces is part of a broader journey:
We want to make business processes programmable.
We want APIs that are not just technical endpoints, but reliable business contracts.
We want discovery, metadata, authentication, permissions, workflows, and task streams to work together.
We want AI agents and external systems to interact with business software safely and meaningfully.
And we know this is not easy.
We are not perfect either. But we are working on it.
For us, Workspaces is not a finished claim that all problems are solved.
It is the direction we are building toward.
A headless Company OS for businesses that want their processes to become more integrated, more automated, and more programmable.
