AKP is the engine Social Labs uses to deliver bespoke AI agents inside large organisations. It is not a licence you take home: it is the technical foundation our team designs, deploys and evolves your operational agents on, and it ships with the connectors for Regentic.AI to govern them.
A kernel of our own, not a project starting from zero
Bespoke development has a well-known problem: every client pays again for the same plumbing. Authentication, persistence, deployment, traceability. AKP exists so that all of that is already done and the project starts with the only part that is genuinely yours — your process.
kernel zone
What we maintain
Execution orchestration, authentication, execution persistence, governance ports and deployment. It evolves with the product and arrives as an update, not as a migration.
Execution engine on LangGraph
Authentication and per-user isolation
Every execution recorded in the database
Policy, tracing and telemetry ports
Containerised deployment and its infrastructure
project zone
What is yours
Your agents, your flows, your integrations and your interface. Full freedom inside your zone, without touching the engine or risking the next version breaking it.
The agents of your operation
The rules and the knowledge of your business
The integrations with your systems
The interface your people see
The data, always on your infrastructure
The separation is not a style convention: the engine code and the project code live in different zones of the repository, and kernel improvements are taken on board without treading on anything your team has written.
agent.manifest
An agent is a manifest and a graph
Adding an agent does not mean touching the engine. It is declared in a manifest — which model it uses, where it is exposed, what limits it has — and the kernel discovers it at start-up and publishes its API on its own.
A declarative manifest per agent: model, routes, limits and interface sections
Automatic discovery and registration at start-up: adding an agent does not force a change to the core
Agents depend on an SDK with a stable public surface, so the engine can evolve internally without breaking them
Execution graphs on LangGraph, with every execution persisted: status, duration, input, output and error
Each agent can bring its own interface, built separately and embeddable in any application of yours
It is the same discipline we ask of a client in governance, applied to the build: if an agent is not declared, it does not exist.
kernel.ports
Governance is not bolted on afterwards: it is a port of the engine
In most projects traceability is instrumented at the end, when compliance asks. Here the core has three ports — policy, tracing and telemetry — and execution always goes through them.
What happens on every execution
01
Policy query
The kernel asks before executing and aborts if the answer does not allow it.
02
Execution with a time limit
The agent's graph runs with a maximum time declared in its manifest.
03
Execution record
Status, duration, input, output and error are persisted and can be queried through the API.
04
Trace and telemetry
The trace is closed and the metrics are emitted to the governance platform.
The kernel queries policy before executing and respects the answer it gets
On finishing, it closes the execution trace and emits its metrics
The adapters are interchangeable: pointed at your Regentic.AI instance, every execution is recorded there
It is switched on with an environment variable; without configuring it, the kernel runs standalone and reports nowhere
If the governance platform does not answer, the kernel degrades in a controlled way instead of bringing the execution down
Where the limit is today, said before you ask
The control point exists in the engine: the kernel asks before executing and obeys the answer. What does not exist today is a policy that says no — the platform answers in observation mode and always allows. Put another way: the control architecture is in place, and what is working is the evidence, not the blocking. We would rather you knew now and not in the technical review.
delivery.milestones
Results in weeks, not in quarters
Delivery is incremental on purpose. First one agent on a real, bounded case; then inside the flow; then several in production. Each milestone is validated with you before the next one opens.
Week 0
Identification
We analyse which processes can be automated and which cannot. What comes out of this is a scope, not a promise.
2–3 weeks
First agent live
In assisted mode, on a real case and with your data. Early enough to correct course while it is still cheap.
4–6 weeks
Inside the real flow
The agent stops being a demo and enters the operation, with impact that can be measured.
8–12 weeks
Several agents in production
Each with its own scope and all under the same governance. From here on, continuous improvement.
What you bring
The knowledge of your key processes
The business rules and the real cases
Collaboration on the testing
The validation of the results
What we bring
The analysis of what can genuinely be automated
The design and implementation of the agents
The integration, the training and the tuning with real data
The monitoring and the evolution afterwards
delivery.sectors
Where we have done it
Sectors in which Social Labs has deployed agents on real processes. AKP is, to a large extent, what was left over from repeating these projects: the place where we consolidated whatever was the same in all of them. The figures are the impact each project reported.
Telecommunications
Cognitive automation of network operations
Agents over network support and monitoring, with the technical knowledge — until then scattered across teams and documents — centralised on a single platform.
in incident resolution times
-40%
in incident resolution times
estimate
in operational efficiency of support and monitoring
+35%
in operational efficiency of support and monitoring
of the technical knowledge, centralised
+80%
of the technical knowledge, centralised
Food
Supply chain optimisation
Agent-assisted document management across the supply chain, with better product traceability and regulatory compliance built into the process rather than reviewed at the end.
in document management time
-35%
in document management time
Banking
Knowledge management for regulatory compliance
Assisted access to the regulatory corpus, with fewer compliance errors and regulatory training that no longer depends on searching the right folder.
in time spent on audits
-40%
in time spent on audits
Health
Clinical knowledge management
Agent-assisted search of medical information, with direct impact on response times in hospital emergency departments.
in medical information search efficiency
+50%
in medical information search efficiency
Industry
AI companion for shop-floor planning and execution
Agents over production planning and rescheduling, working alongside the plant systems already installed rather than replacing them.
in planning and rescheduling efficiency
+45%
in planning and rescheduling efficiency
in unplanned downtime
-30%
in unplanned downtime
in OEE
+22%
in OEE
in on-time delivery
+28%
in on-time delivery
in work in progress and raw materials
-20%
in work in progress and raw materials
You will not see client names on this page: the projects are covered by confidentiality agreements, and we publish the sector and the impact, never who they belong to. If you need a specific reference in order to decide, we arrange it case by case and with the client present.
faq.akp
Frequently asked questions
Can AKP be licensed on its own?
Not as a self-service product. AKP is the kernel we deliver bespoke agents on: what you contract is the project, and the kernel is the technical foundation we build it on. The code of your agents and your data stay on your infrastructure.
What is the difference between AKP and Regentic.AI?
AKP builds agents; Regentic.AI governs them. They are complementary products that share no code: the integration is over HTTP against the platform API. You can contract the governance alone, the build alone, or both.
Do my agents end up tied to your kernel?
The code of your agents is yours and lives in your zone of the repository, separate from the engine. The real dependency is on an SDK with a stable surface, not on the innards of the kernel — which is precisely why that separation exists.
Where does it run?
On your infrastructure. The deployment is containerised, with its proxy, its database and its certificate, and there is infrastructure as code for Azure. It is not a multi-tenant service you send your data to.
Do I need to have Regentic.AI already to start?
No. The kernel runs standalone and the governance connectors are switched on whenever you want by pointing them at your instance. That said, switching them on from the start is the cheap option: instrumenting traceability later, once compliance is already asking, always works out more expensive.
When do I see the first result?
Our reference is two or three weeks to the first agent live in assisted mode on a real case. It is not a laboratory pilot: it is done with your data, and it exists precisely to correct course while correcting it is still cheap.
Tell us which process hurts
The useful conversation does not start with the technology but with the process: which one it is, who suffers it and what would happen if it stopped hurting. That is what tells us whether this makes sense for you or not.