Install Jentic One Beta
Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the agentda, or any other public or private API you need. You set the rules, the agent never sees your credentials, and every call is logged.
Two steps, two machines. Install the instance in a safe environment, then register your agent from wherever it runs.
Step 1: Jentic One Host machine
# On the machine that will host your Jentic One instance:
curl -fsSL "https://jentic.com/install.sh?src=apis&api=%2Fapis%2Fmyagentda.com%2Fmyagentda" | shStep 2: Agent machine
# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL "https://jentic.com/install.sh?src=apis&api=%2Fapis%2Fmyagentda.com%2Fmyagentda" | sh
jentic register # connects your agent to your Jentic One instanceJentic One is in public beta. The setup above keeps your agent separate from the instance, which is what you want before using real credentials: an agent running as the same OS user as Jentic One can read its stored keys directly. Just evaluating? A single local install is fine to start. See the secure deployment guide for the tiers.
What an agent can do with agentda API.
Fetch the user's prioritized agenda as Markdown with GET /api/v1/agenda, narrowing it with scope mine, delegated_by_me, or cc
Search every visible topic with hybrid full-text and semantic matching through GET /api/v1/knowledge/search, optionally limited to one topic
Save a Markdown document with a title, content_md, and source into a topic with POST /api/v1/topics/{ref}/documents
Save a new version of a document with PUT /api/v1/topics/{ref}/documents/{id} and read an older one by passing version
GET STARTED
Pull what changed in a topic since a timestamp with GET /api/v1/topics/{ref}/updates, or read its full append-only history
Create a private or workspace-visible topic with named writers and readers through POST /api/v1/topics
Grant or revoke topic access, rename, or archive a topic with PATCH /api/v1/topics/{ref}
Patterns agents use agentda API for, with concrete tasks.
★ A memory layer for your agent through Jentic
An agent that works across sessions needs somewhere durable to keep what it learns. Through Jentic it finds the agentda operations by intent, searches existing knowledge with GET /api/v1/knowledge/search before answering, and writes new findings with POST /api/v1/topics/{ref}/documents, passing a title, content_md, and a source such as the meeting or URL it came from. Teammates read the same topics, so the agent's notes are shared rather than locked in a chat log.
Call GET /api/v1/knowledge/search with q 'refund policy', and if no snippet answers the question, call POST /api/v1/topics/T-3/documents with title 'Refund policy summary', content_md containing the new findings, and source 'support call 2026-11-09'
Daily agenda briefing
GET /api/v1/agenda returns the user's prioritized overview as Markdown: follow-ups due today, overdue tasks, tasks due today, tasks delegated to others, and remaining open tasks, with snoozed tasks hidden. The scope parameter narrows it to the user's own work, to tasks they delegated, or to tasks they only watch, so an assistant can answer 'what should I work on next' directly.
Call GET /api/v1/agenda with scope mine and summarize the overdue tasks and follow-ups due today in three bullet points
Catching up on a topic
Topics never push changes, so staying current is a pull. GET /api/v1/topics/{ref}/updates returns chronological events since an ISO 8601 timestamp, covering new or changed documents, new members, and newly linked tasks. GET /api/v1/topics/{ref}/history returns the complete, append-only record when the full trail is needed.
Call GET /api/v1/topics/T-2/updates with since '2026-11-02T00:00:00Z' and list the documents that were added or changed
Versioned documents without losing edits
Policies and specs get revised. PUT /api/v1/topics/{ref}/documents/{id} saves a new version while earlier versions stay readable through the version query parameter on GET, so an agent can compare the current text with an older version before proposing a change.
Call GET /api/v1/topics/T-3/documents/{id} with version 2 and again without version, then report what changed between the two
12 endpoints — the agentda api serves a user's prioritized task agenda as rendered markdown and exposes agentda's shared team knowledge base, where knowledge lives in topics referenced as t-1, t-2, and so on.
METHOD
PATH
DESCRIPTION
/api/v1/agenda
Get the prioritized task agenda
/api/v1/knowledge/search
Search the knowledge base
/api/v1/topics/{ref}/documents
Save a knowledge document
/api/v1/topics/{ref}/documents/{id}
Read a document or an older version
/api/v1/topics/{ref}/documents/{id}
Save a new document version
/api/v1/topics/{ref}/updates
Get what is new in a topic
/api/v1/topics
Create a knowledge topic
/api/v1/agenda
Get the prioritized task agenda
/api/v1/knowledge/search
Search the knowledge base
/api/v1/topics/{ref}/documents
Save a knowledge document
/api/v1/topics/{ref}/documents/{id}
Read a document or an older version
/api/v1/topics/{ref}/documents/{id}
Save a new document version
/api/v1/topics/{ref}/updates
Get what is new in a topic
/api/v1/topics
Create a knowledge topic
What agents get from Jentic-routed access to this vendor.
Setup
Wiring agentda by hand means sending its access token in the Authorization header, resolving topic refs that can be a T-number, a name, or a UUID, and staying under the document write limit. Through Jentic you install once, import agentda from the API Directory, store the token once, and your agent calls it.
Permission scoping
agentda puts the topic ref in the URL path (/api/v1/topics/{ref}/...), so a rule can pin your agent to one topic, such as T-3, and the operations you pick. You choose the operations it may call, so ones like deleting documents or changing topic members are not included unless you add them.
Credential isolation
Your agentda access token is stored once, encrypted, by your own Jentic One instance and injected at execution time. It never enters the agent's prompt, logs, or context.
Intent-based discovery
Agents search Jentic by intent such as 'search the team knowledge base' or 'what is on my agenda', and Jentic returns the matching agentda operation with its input schema so the agent calls the right endpoint without browsing the reference docs.
Alternatives and complements available in the Jentic catalogue.
Specific to using agentda API through Jentic.
Is there an agentda MCP server?
You don't need an MCP server to give your agent agentda. Jentic connects it directly from the API Directory: import it, store your agentda access token once, and your agent calls it. Operations are discovered on demand, so no extra tool definitions sit in the agent's context.
What authentication does the agentda API use?
Per its OpenAPI spec, agentda uses an access token sent in the Authorization header as Bearer followed by the token, and the raw token without the Bearer prefix is also accepted. The spec applies it to every operation. Through Jentic, the token is stored encrypted by your own Jentic One instance and injected at call time.
Can I limit what my agent is allowed to do with the agentda API?
Yes. For example, write a rule that allows only GET /api/v1/knowledge/search, GET /api/v1/topics/{ref}/documents/{id}, and POST /api/v1/topics/{ref}/documents under topic T-3. Your agent can then search, read, and add notes in that one topic, but it cannot change members, archive topics, or delete documents, and every call it makes is logged.
What are the rate limits for the agentda API?
The OpenAPI spec states a limit of 120 documents per hour per user for saving new documents with POST /api/v1/topics/{ref}/documents. It does not state a general request limit for the other operations.
How do I save a note to agentda through Jentic?
Search Jentic for 'save a note to the team knowledge base', load the createTopicDocument operation, and call POST /api/v1/topics/{ref}/documents with the topic ref, a title, and content_md. Writing needs topic admin or writer access. To run it on your own infrastructure, install Jentic One from its GitHub repo.
How do I refer to a topic in the agentda API?
The ref path parameter accepts the topic number such as T-3, the topic's unique name, or its UUID. Unknown topics, and topics the user cannot see, return 404, since visibility requires membership or a workspace-visible topic.
Can agentda search find documents by meaning, not just keywords?
Yes. GET /api/v1/knowledge/search runs hybrid full-text and semantic search across all topics visible to the user and falls back to full-text when semantic search is unavailable. The q parameter needs at least 2 characters, and results are snippets, so fetch the full document with the document endpoint.
For Agents
Read a user's prioritized agenda as Markdown, search the shared agentda knowledge base, and save, version, and read Markdown documents inside knowledge topics.
Use for: What is on my plate today, Show only the tasks I delegated to other people, Search our knowledge base for the onboarding checklist, Save these meeting notes into the T-3 topic
Not supported: Does not create, complete, or reassign tasks, and it does not host files other than Markdown documents. Use for reading the agentda agenda and searching and writing its team knowledge topics only.
The agentda API serves a user's prioritized task agenda as rendered Markdown and exposes agentda's shared team knowledge base, where knowledge lives in topics referenced as T-1, T-2, and so on. Agents can list and create topics, save versioned Markdown documents of up to 4 MB into them, read any earlier version, and run a hybrid full-text and semantic search across every topic the user can see. Each topic also has a pull channel of what changed since a given time and a complete, append-only history, and topic admins can add writers or readers, switch visibility between private and workspace, rename, or archive a topic.
This API is usable in Jentic One now. Its AI-readiness score against Jentic's framework shows where it stands today and where improvements would make it even easier for agents to use.
Base layer of spec validity and structural soundness.
Aggregated quality score from linter diagnostics, weighted by severity.
Percentage of `$ref` references that resolve successfully.
Checks whether the API description parses successfully and conforms to its declared specification (e.g., OpenAPI).
Structural correctness score based on schema issues using logarithmic dampening.
Clarity, completeness, and ingestion readiness for developers and tooling.
How richly the API is illustrated with examples.
Percentage of examples that conform to their schemas.
Percentage of operations with complete response definitions (success, client error, server error).
Health of API ingestion, bundling, and resolution within Jentic pipelines.
Semantic breadth, depth, and agent comprehension for AI systems.
Coverage of descriptions across API elements.
Coverage of RFC 9457 Problem Details for error responses.
Coverage, uniqueness, and casing consistency of operationIds for AI inference.
Coverage of summaries across operations/tags/info.
Functional utility, complexity comfort, and AI orchestration readiness.
Agent comfort level based on API operational and structural complexity.
Trust, risk posture, and security compliance.
Average quality of security schemes based on authentication method strength (weakest link for OAuth2).
Findability, semantic richness, and reasoning readiness.
Clarity and depth of descriptions across API elements.
Score it yourself
Every API in the directory is allowlisted, so you can re-score it with no key required.
npx @jentic/api-scorecard-cli score <openapi-url>