Knowledge infrastructure that gathers your company's knowledge into one durable memory, gives every AI tool the same truth, and knows when each thing was true.
Three Assistants, Three Different Answers. The Problem Is Memory, Not the Model.
Companies moving to AI tend to stall in the same place: each tool knows half the story, one forgets yesterday's decision, another quotes a price cancelled two months ago. We separate knowledge from the tools and move it into one enterprise memory. Every agent reads from the same source, and a new AI tool inherits the company's entire knowledge on its first day.
We build memory with time in it. A new decision does not delete the old one, it supersedes it — even "what did we know in March?" has an answer. Retrieval scores meaning, importance and recency together; precise questions go to structured queries, vague ones to semantic search. Embeddings are generated on your own infrastructure, and retention periods follow data-protection rules.
What We Build
Bi-temporal enterprise memory: version chain, supersede, never delete
Source classification: public, internal and confidential knowledge managed apart
One memory served to every agent over MCP; Linear, Drive and CRM connectors
Local embeddings and retention periods aligned with data-protection law
Where It Fits
Proposal and contract drafting, on-brand content production, team and project status reports, product catalogue search, internal knowledge bases and customer support knowledge.
In Our Own Projects
APEX: Unitic's own collective AI brain — our conversation, coding and content agents run on the same memory. Hardiye: product search over a 150-item catalogue that routes precise requests to a structured query in milliseconds and vague ones to semantic search.
AI Agent Systems & Orchestration
An architecture that runs several AI agents on one brain, one shared tool registry and clear permission boundaries — with every write gated by human approval.
One Smart Assistant Is Easy. Ten That Don't Break Each Other Is Not.
As agents multiply, so do the questions: which agent may touch which data, who changed what, can one failure cascade? We answer them in the first line of the architecture, not afterwards. Every agent reaches its tools through a single registry; every tool is contracted, typed and audited.
Autonomy comes in stages. The agent reads and drafts; writes go through human approval, and critical operations never run autonomously. The AI can never exceed the permissions of the person using it; identity and tenant context always come from the server, never from the model. Specialist agents hand work to each other, but all of them draw on the same memory and the same rules.
What We Build
One brain, many surfaces: chat, panel, automation and external agents share one core
Contracted toolsets over MCP and external agent integration
Staged autonomy: read → draft → human approval → apply
Handoff between specialist agents (orchestrator → specialist)
An audit record on every call, publish approval queues and locks
Where It Fits
Assistants embedded in SaaS products, AI-managed content and websites, operations and internal process agents, agent teams that work in tools like Linear and the CRM.
In Our Own Projects
Motice: an assistant layer where the interface and the AI pass through the same door and risky writes are bound to approval cards. Anvil: content infrastructure where the agent edits the site only through typed tools and every change moves from draft to approval. APEX: a company setup where conversation, coding and content agents share one MCP brain.
LLM Security & Data Protection
A security layer that controls, proves and measures on every release which data goes to external AI models, for what purpose and to which provider.
"Is Our Data Going to the Model?" — "We Don't Think So" Is Not an Answer.
The moment a company starts using LLMs, customer, finance and staff data can leave inside a prompt. We narrow that path to a single egress gate. Everything bound for the model passes through it first, and in any undefined situation nothing is sent.
Personal data never reaches the model: names and record IDs become pseudonyms scoped to the conversation turn and the business, and are restored on the user's screen as the answer streams back. Unless the provider's commitments on training, retention, data region and data-protection law are on record, no call is made with real data. We don't hide the residual risk either: every release measures leakage with the same question set.
What We Build
A fail-closed egress gate: no call without policy and purpose context
A pseudonym vault: personal data never reaches the model
Field manifests: what may be shared is declared field by field
Provider contract evidence: training, retention, data region, data-protection law
An ID-provenance gate: the model only uses identifiers it has actually seen
Role-based leakage measurement on every release
Where It Fits
SaaS products that handle customer data, regulated sectors such as finance and health, internal AI usage policies and any AI project under data-protection law.
In Our Own Projects
Motice Shield: the protection layer behind Ask Motice, Motice's AI assistant. Its core was designed as a package independent of Motice, so the same protection can move to other products.
Provable AI: Evals & Observability
AI systems where every answer is measured, every failure is traced and every release is tested.
An AI Demo Works Once. AI in Production Has to Prove Itself Every Day.
Most AI projects stop at "we tried it and it looks fine". We treat AI like any other software: we test it, measure it and catch regressions. We test our voice assistants by putting them in conversation with another AI playing the customer; the conversation's event timeline is verified automatically against written scenarios.
We don't treat latency as one number. We measure a sentence's mouth-to-ear journey step by step and know where every second goes. Privacy is a test, not a claim: every release measures, with the same question set, whether the model leaks personal data. Every call is traced end to end, and cost and latency targets are part of the scenario tests.
What We Build
LLM-simulated customer tests: agents talk to synthetic customers before real users
End-to-end latency telemetry with backend, model and avatar shares split
Privacy and leakage evals: role-based question sets on every release
Scenario tests with cost and latency targets
Per-session end-to-end traces and error tracking in Langfuse
Where It Fits
Any customer-facing AI product, AI in regulated sectors, and teams taking AI from pilot to production.
In Our Own Projects
Hardiye's speech-to-speech test harness and latency breakdown, Motice's leakage measurement on every release, and APEX's cost-capped scenario tests.
Voice & Video AI Assistants
Voice and video AI assistants that speak Turkish 24/7, recognise returning customers by face, quote live price and stock from the catalogue and look up orders.
A Voice Agent Is Not a Chatbot With a Microphone.
A conversation stops feeling human the moment the reply starts to lag. That is why we build the voice line as a streaming problem, not request and response: audio streams in pieces over WebRTC, the model reasons over partial input, and the reply is voiced before it is complete. Interruptions, turn-taking and silence detection are part of the design from the start.
The agent doesn't just talk, it acts: it answers from live price and stock, looks up orders and shipments, scans QR codes and barcodes, and greets returning customers by name after recognising their face — without storing photos. A possibly misheard product name or phone number triggers a spoken confirmation. Every conversation is traced end to end.
What We Build
Real-time conversation over WebRTC (LiveKit, Gemini Realtime / Live)
Video avatars and face recognition for personalised greetings
Spoken confirmation loops for numbers and product names, tuned for Turkish
Handoff between specialist personas and lead capture into the CRM
Latency telemetry and speech-to-speech tests with synthetic customers
Where It Fits
24/7 customer support, in-store and field assistants, greeting and qualifying leads in the first minute, appointments and reservations.
In Our Own Projects
Hardiye: a 24/7 Turkish-speaking sales and support assistant for Hardline Nutrition, with a video avatar and face recognition, and live price and stock across all 150 products. In Unitic's own lead-intake agent, handoff between an orchestrator and specialist personas.
Verified Vision: Identity, Documents & Faces
Computer vision systems that anchor ID trust in MRZ check digits rather than OCR, read paper exam forms, and recognise faces without storing photos.
Reading an Image Is Easy. Knowing the Data Is Right Is Not.
Data still lives on paper, in photos and on cards. We don't stop at reading it; we verify it. On ID cards we anchor trust in the MRZ check digits on the back, not in front-side OCR; on paper exam forms we align the image with registration marks and send ambiguous marks to a person instead of guessing.
When the system cannot be sure, it reports instead of guessing. Privacy is part of the design: we match faces as mathematical signatures, not photos, and we develop models on synthetic data we generate rather than real personal data. We measure accuracy on real documents, not on demo data.
What We Build
Identity document extraction and ICAO 9303 MRZ validation
Face matching, liveness and anti-spoofing checks
Optical exam form reading from DAT files, PDFs and images, with registration-mark alignment
Product and document recognition by QR code and barcode
Document and certificate verification portals
Training on synthetic data and accuracy measured on real documents
Where It Fits
Remote customer onboarding (KYC), paper exam scoring, certificate verification, accounting and paperwork automation, personalised greetings.
In Our Own Projects
UNITICID: our identity verification pipeline built on mathematics. An optical reader for paper exam forms and a certificate verification portal, built for the Yunus Emre Institute. Face recognition and QR/barcode reading in Hardiye.
Network-Level Protection: Addiction & Digital Health
Apps that block harmful domains on the device and the network before a connection is made, and protect against addiction with risk assessment and a support network.
A Blocklist Never Freed Anyone From Addiction. A System Can.
In protection apps the point is not a single tool but a system whose parts reinforce each other: understanding the user's risk, building real protection on the device, and keeping a support network close. With on-device DNS protection on Android, a signed DNS-over-HTTPS profile on iOS and our own resolver on the server, harmful domains are blocked before a connection is even made.
Blocking rules match in constant time at large scale; the list is fed from curated sources and the allowlist always wins. When protection is switched off, the supporter the user chose is notified. Because these apps run on the operating system's most sensitive permissions, we test every flow on real devices with failure and permission scenarios, and we document platform limits openly.
What We Build
On-device DNS protection on Android (VpnService) that survives reboots
Signed, per-device DNS-over-HTTPS profiles on iOS
Our own DoH resolver and a large-scale blocking rule engine
Risk assessment questionnaires and relapse-prevention flows
Supporter alerts, progress screens and account deletion under data-protection law
Where It Fits
Support for addiction treatment, parental controls, corporate device policies and digital health programmes.
In Our Own Projects
BGB: an app and admin panel against gambling addiction that combines network-level protection on iOS and Android, risk assessment and supporter follow-up.
SaaS Engineering: Multi-Tenant Architecture
SaaS architecture that serves one product to hundreds of businesses, none ever able to see another's data at the database level — proven, with tests, across four separate products.
In SaaS, the Most Expensive Mistake Is One Customer Seeing Another's Data.
We don't leave tenant isolation to the good intentions of application code; we build it into the database itself. Every tenant table is protected by forced PostgreSQL row-level security (RLS), and the application connects with a role that cannot bypass it. A single table missing its policy breaks the build. We apply this approach, with its tests, across four separate products.
Access is never granted on a role alone: the user's role, the data scope they see, the business's plan and the current state are evaluated together, and the interface, API, reports and AI enforce the same boundary. The commercial layer is part of the product too: plan and feature access, subscriptions, payments and invoicing. Tenants can be split by subdomain, country or branch.
What We Build
Forced database-level RLS with coverage tests
Authorization by role × data scope × plan
Subscriptions, plan and feature access, payments and invoicing
Tenant structures by subdomain, country and branch
Per-tenant configuration and white-label
Where It Fits
Vertical SaaS products, multi-branch and franchise businesses, platforms licensed to institutions, and multi-country institutional networks.
In Our Own Projects
Motice: a multi-tenant CRM/ERP for pilates, yoga and studio businesses. Keyperties: a B2B2C platform connecting real-estate advisors with residential developments. Mentorual: a mentoring and booking platform offered to institutions, starting with İTÜ Ginova. The Yunus Emre Institute's web network, running 93 centres in 69 countries from one codebase.
Enterprise Platform Engineering: Audit & Data Integrity
Enterprise platforms whose rules are guarded in the database and whose every step is tracked in a tamper-evident record — from the Yunus Emre Institute's education and exam system to booking and sales flows.
An Exam Result Cannot Be Wrong. If It Is, "Who Changed What, and When?" Must Already Have an Answer.
In exams, certificates, applications, bookings and sales, software carries an institution's credibility. We build these platforms as separate domains: one shared identity layer, but each domain owns its data. Events are designed never to be lost or processed twice, and files are not accepted until they pass quarantine and a virus scan.
Rules live in the database as well as the application: two bookings for the same slot are impossible at the database level, and whoever grades an exam paper cannot approve it. With tamper-evident, hash-chained audit logs and versioned certificates, every result can be verified after the fact.
What We Build
Shared identity, a separate database per domain and service-to-service JWKS verification
Transactional outbox: event flow without loss or duplication
Business rules guarded by database constraints: no double bookings, maker-checker
Hash-chained audit logs, versioned and verifiable certificates
Lock, quote and commission state machines
Where It Fits
Exam and certification systems, education and course management, public application processes, booking and sales flows, multi-centre institutions.
In Our Own Projects
An education management and Turkish proficiency exam platform for the Yunus Emre Institute. Apartment lock, quote and commission flows in Keyperties. Database-level double-booking protection in Mentorual.
Blockchain & Smart Contract Solutions
Smart contracts, on-chain verification and blockchain solutions integrated with existing systems, for places where several parties must trust the same record without trusting a single centre.
Blockchain Is Not the Answer to Every Problem. Asked the Right Question, It Is a Strong One.
We treat blockchain as an architectural decision, not a trend. The first question is always the same: is this record kept by several parties, none of whom should have to trust another alone? If yes, a shared, immutable ledger creates real value. If no, a well-designed database is cheaper, faster and easier to run. We draw that line openly during discovery.
Where blockchain is the right answer, we do not cut the chain off from the rest of the business. Smart contracts carry the business rules; identity, payments and reporting talk to existing enterprise systems. Personal data is never written to the chain. Only the proof needed for verification lives there: a hash and a signature. That way the right to erasure and an immutable record never collide.
What We Build
Smart contracts: design, development, testing and independent review
On-chain verification of documents, certificates and records by hash and signature
Tokenisation of assets and rights, digital certificates and loyalty tokens
Architecture choice between permissioned and public networks
Wallet, identity and signing flows; integration with ERP, CRM and payment systems
Where It Fits
Supply chain and provenance tracking, diploma and certificate verification, inter-organisational reconciliation, asset tokenisation and any multi-party process that has to stay auditable after the fact.
Our Foundation
Immutable records are not new to us: on our enterprise platforms, critical changes are already written to hash-chained audit logs that can be verified after the fact. Blockchain takes that principle beyond the walls of a single organisation, onto a ledger shared by several parties.
