Context
We bring together the relevant authorised sources for the project.
Products Taskin
Work organisation Development & demonstrations
What we have established. Who continues. What is next.
Taskin explores turning discussions and project context into commitments, priorities and work steps. The aim is to keep the link between a task and the conversation from which it emerged.
- 1Discussion and context
- 2Sarcini propuse
- 3Angajamente confirmate
Taskin
From information to work done.
Angajamente
We identify the decisions and action items for team review.
Continuity
We organise responsibilities and follow-up on confirmed steps.
Where it becomes useful.
Projects
Reconstructing decisions and priorities without losing context.
Meetings
Task proposals from discussions, reviewed before use.
Operations
A direction for coordination between people and AI agents.
The functions and connections are in development. We do not assume that any decision extracted automatically is correct or approved.
Taskin in detail
What you can do with this project.
Taskin is a work board with a particular feature: it does not wait for you to enter tasks. It reads what has already happened — calls, email, calendar, messages, commits, work sessions — and suggests what should be done, together with the evidence from which the suggestion arose.
The distinction it builds is between what was observed and what was decided. An automatically proposed task does not become a commitment until a person confirms the assignee, deadline and wording. This rule is not a UI promise, but a restriction enforced in the database: an agent cannot close a task, and any write that closes one must declare who requested it. A write without a name is refused.
We use it ourselves. Almost everything interesting in it appeared because we were missing something concrete in running our own company, and the comments in the code cite real production counts and dated incidents — including one in which a daily routine went silent for eleven days in a row without anyone finding out.
A complete board, not an experiment
50 routes across 49 pages: teams, cycles, projects, tasks, inbox, roadmap, day plan, clients with file and history, recurring expenses, invoicing, timesheets and work sessions, performance, internal chat, administration and members. The database has 90 tables, built from 81 migrations.
The collector: 21 loops that bring reality onto the board
Scheduled routines on the server, not process timers — because a timer is lost on every redeploy. Each run goes through a wrapper that writes a log and treats even an HTTP 200 response as a failure if it carries a list of errors, with an alert on Telegram. The wrapper exists because, before, a command that failed silently left the daily briefing dead for eleven days.
MCP server: the same queue for people and for agents
14 tools over HTTP — read (list, search, my queue, agents' queue, board summary, people, agents, projects) and write (create, update, assign, move, comment). Each access token is linked to a real profile, so board activity records who requested it. An AI agent and a colleague work on the same list, with the same rules.
Real integrations, named as such
Telegram, as a dedicated bot with permanent listening, including transcription of voice messages. Four mailboxes (three Gmail and one Microsoft 365), read exclusively in read-only mode. Google Calendar. Phone calls, via SIP trunk, including reminder calls initiated by the board. Obsidian. LinkedIn. The models pass through a proprietary OpenAI-compatible gateway, and the agent execution engine uses a tool loop over OpenRouter.
The rule that agents cannot bypass
“An agent does not close a task” is a function in the database, not a sentence in a tool description. It got there because the first version did not work: it identified the actor in a way that came out empty for an automated service, so the rule did not apply anywhere. Now the actor is resolved from three successive sources and, if it cannot be established, the request is refused.
Data and operation
What enters the system. What needs to be checked.
- Organisation-level isolation, verified at row level
- All 90 tables have row-level access enabled, under 171 policies. The internal rule is written and without exceptions: a new table means an access policy on it. The role hierarchy goes from Super Admin to Admin, Member and Employee.
- Sources are read, not copied
- The mailboxes are connected in read-only mode by design, not by configuration. Work sessions and git activity are read from the person’s computer, not from the server. What reaches the board is a trace, with a link back to the source, not a copy of the correspondence.
- The data sits on our own infrastructure
- Supabase hosted by us on an Azure machine, not Supabase Cloud — Postgres, Kong, Auth, Realtime and Storage in Docker Compose. The database address is a path on our own domain. Migrations are applied manually, deliberately: there is no automated step that touches the production schema.
- What a language model sees
- The loops that summarise, link and judge send content to models. Four of the nine internal loops disable themselves, with an explicit message in the log, when they lack credentials — so the absence of a key stops the flow, rather than letting it run half-way.
From exploration to implementation
How we prepare a project with Taskin.
We start from a single source and a single project
We do not connect everything. One source — usually mail or Telegram — and one real project, so that on real data it can be seen what the system proposes and how useful what it proposes is.
We compare proposals with real decisions
The period in which the system proposes and the team only confirms or rejects is what shows whether it is worth continuing. A rejected proposal is as informative as an accepted one.
We set the closing and assignment rules
Who can close what, what a term means and what happens to a task without an assignee. This is also where it is decided whether agents are allowed to write on the board, and under what conditions.
We install on the agreed infrastructure
Delivery is by rsync to a machine, not a container: the interface as static directories served by nginx, the collector and the MCP server as systemd services. The health check compares the served package with the built one and rolls back if they do not match.
Questions worth clarifying.
Is it a finished product or a demonstration?
It runs in production and it is the board on which we run our company. The figures: 566 commits, the last on 4 September 2026; 81 migrations that build 90 tables; 171 row-level access policies; 563 automated test cases in 38 files; 21 scheduled routines on the server plus 9 loops in process; 14 MCP tools; 35 endpoints on the collector. What it is not: a self-service product. There is no button by which an external team can start it on its own — it is installed.
Does it decide automatically who works?
No, and the restriction is in the database, not in the interface. A guard-style function prevents an agent from closing a task, and any write that closes one must declare the actor; if the actor cannot be established, the request is rejected. It is also worth saying why the rule looks like this: the first version identified the actor through a function that returned empty for an automated service, so it did not apply anywhere. An internal audit found it, and the migration that fixed it explains in a comment exactly what was not working.
What does it connect to, concretely?
In practice, with code and with scheduled routines: Telegram (own bot, permanent listening, transcription of voice messages), four mailboxes — three Gmail and one Microsoft 365 — read only, Google Calendar, phone calls via SIP trunk, Obsidian, LinkedIn, plus work sessions and git activity read from the person's computer. The models go through a proprietary OpenAI-compatible gateway; the agents' execution engine runs on OpenRouter. What is NOT connected, although our integrations page displays it: Slack, GitHub, Jira, Notion, Figma, Zapier, Dropbox, Google Drive, Microsoft Teams, GitLab, Outlook. We searched the code and there is no line for any of them. That page is a marketing grid and needs correcting.
Is there WhatsApp integration?
No, despite the name of a screen in the application. That screen is in fact device pairing by QR code, in the style people are used to from WhatsApp Web — that is where the name comes from. There is no call to any WhatsApp API. More: that flow is unused, and its tables are empty, something that is stated by the migration that revised their permissions.
How is security handled, beyond statements?
The useful part is not that we have access policies, but that we found their gaps and fixed them one by one, each migration explaining what was not working. An internal audit in August found that all three agent fences were inert. Another fence turned out to be fail-open — the check was skipped entirely, not rejected — and was reversed to fail closed. The third problem was subtle and general: in Postgres a new function is executable by everyone by default, so explicitly granting rights did not restrict anything; it was verified in production that an anonymous key reached the function body, then the default right was revoked. At repository level, a fence rejects direct pushes to the main branch and blocks secret files, because a private repository on a personal account cannot have branch protection from GitHub.
What is not finished?
Three things we prefer to say. The generated types for the database date back to January and contain tables from a completely unrelated project, which forced 101 forced type conversions in 26 files — it works, but loses compile-time checking exactly where it would help. The style checker reports 161 inherited errors and does not block delivery. And 36 tests are skipped in continuous integration because they need a model key that does not exist there. None of them stops the product; all three are real debt.
How is it installed and how secure is the delivery?
By rsync, not a container: the interface ends up in a static directory served by nginx, the collector and the MCP server run as systemd services. Continuous integration runs the tests and builds; delivery starts only if those have passed on the main branch, through a proprietary executor that is allowed to run exactly two scripts and nothing else. Each external action in the pipeline is pinned to its full fingerprint, not to a tag, after the compromise of a popular action in March 2026. The health check reads which package the served page refers to and rolls back if it is not the fresh one — a rule written after a real incident on 3 September 2026. Database migrations remain manual, deliberately.
Illustrative example
A phone call becomes a task with proof attached
A use case, without client data or attributed commercial results.
Initial situation
A call ends with a promise. No one writes it down anywhere, and a week later no one remembers either what was promised or to whom.
How it works
The call enters the board through a scheduled routine, as a trace with a link back to the source. A loop connects it to the relevant client file and suggests a task with an assignee and a deadline. The proposal remains a proposal: the gate in the database does not allow an agent to close it, and the write operation that would close it must declare who requested it.
Rezultatul
The task appears with the context from which it resulted attached, so that a colleague who was not on the call can understand what needs to be done without reconstructing the discussion. A person confirms the assignee, the deadline, and the wording — or rejects the proposal, which is just as informative.
What is required:The source must be effectively connected, with authorised access, and there must be agreement within the team on what an assigned task means. The system does not assume anyone's consent.
Collaboration possibilities
Taskin, in your organisation's context.
Internal flows and information
Connecting authorised sources, organising information and reviewing actions by the team, with separate access by role.
Private companies
We define a pilot around a real process: users, data, integrations, costs and acceptance criteria. Expansion follows after evaluating the result.
State institutions and companies
We establish the requirements for accessibility, hosting, data protection and interoperability. Any connection to AGE or STISC services requires validation of eligibility, access and approvals.
These are adaptation scenarios, not statements about existing contracts or partnerships. The proposed functions are confirmed within the project scope.
Discuss a pilotPart of an ecosystem.
Conversations and support
aichat
An assistant connected to your business information, in the channels your customers actually write to.
PlatformInformation and coordination
Cronberry
Cronberry brings authoritative sources, conversations and relationships together in one space for research and coordination.
Development & demonstrationsConversational forms
Megaforms
Megaforms explores collecting answers through conversational forms, including spoken answers and transcription.
Development & demonstrationsWhat would you want to work better?
Tell us about your process. Together we decide what is worth building, what we can connect, and how we check the result.