Inkpilots

Agents and Libraries

Workspace

The Agents and Libraries area is where Inkpilots turns a repeatable editorial process into a repeatable operating system. Agents let your workspace generate content on a schedule or in controlled batches. The library gives those agents reusable source material that can be attached, reused, and governed at the workspace level instead of being recreated inside every prompt.

This page should be read as a handbook for operating automation safely. The goal is not only to create output. The goal is to create output that stays aligned with your workspace rules, editorial cadence, and content standards.

Content

  • automate recurring article generation,
  • run a one-time batch of articles for a planned campaign or backlog,
  • keep generated output tied to a specific workspace,
  • attach reusable reference files to support more consistent results,
  • control which tools an agent can use during generation.

Agents are best understood as managed production workers. They are not free-floating prompts. Each agent belongs to a workspace, carries its own configuration, and is expected to operate inside a defined editorial model.

How to setup an agent

Each agent is configured with a name, a prompt, a model, an output language, and an execution mode. After creation, the agent appears in the Agents tab where the workspace can monitor its current status, view its schedule, and inspect basic run statistics.

The current agent surface supports:

  • active and inactive agent states,
  • scheduled and batched execution modes,
  • hourly, daily, weekly, or monthly schedules for scheduled agents,
  • model selection,
  • output language selection,
  • optional image generation,
  • optional web search,
  • optional file-backed search and context,
  • run counters such as total runs and successful runs,
  • next-run countdowns for active scheduled agents.

This means the product is not only storing prompts. It is storing an operational definition of how recurring content should be produced. Agent execution runs on Batching, Batching means instead of immediate results, instructions wait in a queue for execution when queue is available. This way way system has less cost.

Choosing the right execution mode

Scheduled agents

Scheduled mode is for recurring production. Use it when the workspace needs content to be generated at a regular cadence, such as daily, weekly, or monthly If output is binded to dynamic resources like websearch this type of agent is right tool to use.

In the current product, scheduled agents can be configured with:

  • a recurrence interval,
  • an optional maximum article limit,
  • automatic activation after creation,
  • a visible next-run timestamp and countdown in the agent card.

Scheduled mode is appropriate when the team already understands its editorial rhythm and wants the system to maintain it consistently. Recommendation: Instead of auto publishing content, review and modify the content, due to EEAT rules content may have less traffic. Updating results will give you higher quality scoring.

Batched agents

Batched mode is for one controlled run that generates a defined number of outputs in a single pass.

Use batched mode when your team wants to:

  • create a backlog of draft content,
  • generate a set of articles for a campaign,
  • test a prompt and model combination against a known volume,
  • avoid ongoing recurring execution.
  • you can not run batched configured agents more than once.

Batched mode requires a batch size. It is usually the better choice when you want volume without turning the agent into a standing recurring process.

Most important part of the agents, they remember the previous output. This ensures same content will not be generated twice.

What you configure when creating an agent

The create-agent flow currently exposes the core decisions that determine output quality and operating behavior.

Identity and instruction

  • Name gives the agent an operational identity inside the workspace.
  • Prompt defines the behavior and generation instruction set.

Treat the prompt as a working production brief, not as a marketing slogan. A weak prompt usually creates broad, unstable, or repetitive output.

Model and language

  • Model controls which LLM is used.
  • Language defines the target output language.

These settings matter because automation is only useful when the output format matches the destination workflow.

Volume and cadence

  • Schedule is required for scheduled agents.
  • Max articles can be used to stop a scheduled agent after a defined amount of output.
  • Batch size is required for batched agents.

This is where teams should express real capacity. If the configured volume is larger than your review and publishing capacity, the system will generate faster than the team can govern.

Tools an agent can use

Inkpilots agents can be created with optional tool access. These choices should be deliberate because they shape both output quality and operational cost.

Image generation

Enable image generation when the workspace expects articles to include image assets or image-ready content blocks as part of the final output. Current implementation supports low quality images, agent generates maximum three images per article.

Use it when imagery is part of the publishing workflow. Do not enable it by default if the team has no image review process.

Web search

Enable web search when the content depends on current facts, external sources, or up-to-date public information.

The agent form also supports domain restrictions for web search. This is important when your team wants research constrained to approved or trusted sources instead of the open web. Using tools will increase quota consumption.

File search and file-backed context

Enable file-backed context when generation should reflect reusable internal guidance rather than only the prompt.

In practice, this matters for:

  • brand or tone references,
  • reusable factual background,
  • internal process guides,
  • policy or product context that should persist across runs.

File-backed context can be enabled directly, and it is also implicitly enabled when a context file is attached to the agent.

What the library is for

The workspace library is the reusable file layer for automation. It exists so important reference material can live at the workspace level instead of being copied into every agent configuration.

The current library surface allows workspace users to:

  • upload files into the workspace library,
  • view filename, size, and upload date,
  • delete files that are no longer needed,
  • reuse previously uploaded files when creating agents.

This is an important distinction. The library is not just storage. It is the controlled context layer that helps keep automation consistent across time.

How files are used with agents

When creating an agent, the workspace can either upload a new file or reuse a file that already exists in the workspace library.

That workflow is valuable because it separates two different responsibilities:

  • the library stores reusable reference material,
  • the agent decides whether that material should be used for this specific automation job.

From an operating perspective, that is much better than rewriting the same background material into multiple prompts. It reduces duplication, makes changes easier to govern, and gives the team a clearer source of truth.

At the moment, direct file attachment in the agent creation form is validated conservatively, while the shared library acts as the broader reusable file store for the workspace.

What the agent cards tell you

After an agent is created, the Agents tab becomes the monitoring surface for day-to-day automation management.

Each agent card currently exposes:

  • the agent name,
  • the configured schedule label,
  • whether the agent is active or inactive,
  • a shortened view of the prompt,
  • total run count,
  • successful run count,
  • enabled tools such as file search, image generation, and web search,
  • the next generation countdown for active scheduled agents,
  • the last run date when available.

This is the information operators should use to answer practical questions such as:

  • is this agent currently live,
  • what cadence is it supposed to follow,
  • has it been running successfully,
  • what capabilities does it have enabled,
  • when should it run next.

Recommended operating practice

Build the manual workflow first

Agents work best when the workspace already has a clear planning and review model. If the team does not yet know what good output looks like, automation will usually multiply uncertainty rather than reduce effort.

Use scheduled mode for stable recurring work

Do not use scheduled agents to discover your process. Use them to scale a process that already works.

Use batched mode for controlled experiments or campaigns

Batched runs are better when the team wants a bounded content push without adding another ongoing automation stream.

Treat library files as durable reference material

Only store files that deserve to be reused. If the library becomes a dumping ground, file-backed generation quickly becomes less trustworthy.

Review tool access intentionally

Every enabled tool changes how the agent behaves. Web search changes the source base. Image generation changes the output shape. File search changes the internal context. These are editorial decisions, not just technical toggles.

Common mistakes to avoid

  • Creating agents before the workspace has clear topic planning and publishing standards.
  • Using scheduled mode for work that should have been a one-time batch.
  • Setting content volume higher than the team can realistically review.
  • Enabling web search without deciding which sources should be trusted.
  • Uploading library files without a clear reuse purpose.
  • Treating the prompt as the only source of control when stable context belongs in the workspace library.

When to use this area with other guides

Use this page together with:

Related guides