AI engineering coworker
Not an AI agent. Your next colleague.
Bring an AI coworker onto your team. Jigward takes on engineering work across your tools and carries what it learns about your product into the next task.
Currently in closed testing.
Microsoft Teams — coming soon
A fix handed over in Slack
# cab-backend
@Jigward dispatch says rides to Moon Base 2 cost ten times more after midnight UTC. Can you find out why and fix it?
3 replies Last reply just now
Thread # cab-backend
Replies
26 minutes later
An issue assigned to Jigward
Fares to Moon Base 2 jump tenfold after midnight UTC
Description
Riders booking a trip to Moon Base 2 after 00:00 UTC are quoted ten times the daytime fare.
- Route has ten legs.
- Daytime bookings are unaffected.
Activity
A conversation on a draft pull request
volkoff-studio / orbit-cab⌕ Type / to searchAdd the night surcharge once per ride #36
Jigwardbotopened this draftThe night surcharge was being added on every leg. This change applies it once per ride.
The pull request stays a draft. A person decides when to merge.
- Reviewers
- Tech lead
- Assignees
- Jigward
- Labels
- bug
- Linked issue
- CAB-6
- Checks recorded
- 46 tests passed
A private Chat about a new feature
Jigward/ orbit-cab / ChatSearch this ContextMeteor warnings per route
orbit-cabYour Chat is private. The Context’s knowledge can inform the answer.
A shared notification checklist for the team
Jigward/ orbit-cab / ApplicationsSearch this ContextNotification checks
orbit-cab · Team ApplicationNew notifications
One notification per event. Respect preferences.
Open the right booking.
Feature checklist
2 of 4 checkedCreate a booking and check the notification.
Send the same booking event twice.
Turn notifications off before creating a booking.
Follow the notification link.
Hand the problem to your coworkerQA found two notifications for one booking. Ask Jigward to investigate and propose a fix.
What Jigward is
A coworker that belongs to your organization, not to one desk.
Jigward joins your organization the way a new engineer would: it reads your repositories, learns the project, and takes work from anyone on the team. That work happens in Contexts.
One colleague for everyone in the organization. We do not plan to cap the number of members who can work with Jigward.
A Context is one area of work, shared.
A Context holds a product’s repositories, its Tasks, Chats, Duties and Applications, and what Jigward knows about it. Everyone working on that product works in the same Context with the same Jigward, so an analyst’s question and an engineer’s fix land in one place.
- Business analyst
- QA engineer
- Backend engineer
- Tech lead
Jigward
- Repositories orbit-cab
- Tasks from the web, Slack, Jira, GitHub
- Chats private to each member
- Duties weekdays at 8:30
- Applications Launch pipeline
- Project knowledge schema, API, what was settled
- GitHub
- Slack
- Jira
- CloudWatch Logs
- Browser
- Custom API
-
Works on its own
Give it a Task and it carries the work to a report and a draft pull request without anyone watching, asking only where it cannot go on responsibly.
-
Keeps going while you’re away
Duties wake on a schedule — every weekday morning, every half hour — read what changed, report, and give a Task when engineering work is needed.
-
Knows the project
Database schemas from the migrations, API operations from OpenAPI, dependency trees, and what the team settled, each with where it came from.
-
Builds the team’s tools
Ask for an Application — a page with its own data and charts — and Jigward builds it, keeps every version, and lets it react when a Task ends.
-
Connects to your systems
GitHub, Slack, Jira, CloudWatch Logs and a browser, and any HTTP API you describe: Jigward drafts it as a custom integration an admin applies, and its key never reaches the model.
-
Answers where you are
In the Slack thread, on the Jira issue, on the pull request, or in a private Chat — and the report goes back where the work was given.
How it works
Connect it once. Then ask, the way you would ask a colleague.
-
Connect
An admin connects GitHub, then Slack, Jira, CloudWatch Logs or a browser profile as the team needs them. Repositories are grouped into Contexts, one for each product or team.
-
Ask
Mention Jigward in a thread, assign it an issue, request its review, or open a Chat in the web app. Anyone in the organization can.
-
Read the result
Jigward reads the code before it changes it, proposes changes as draft pull requests, runs the repository’s tests and reports where the work was given, with its verdict: Done, Partly done or Blocked. A person merges.
Use cases
See it on a problem your team already has.
Each case is a short film and a page: what the team asked, what Jigward did across its tools, and what came back.
-
When production breaks
Errors doubled after a release. Was it the deploy?
-
Before a release ships
Every check is green on a column drop. Does anything still read it?
-
Keeping main healthy
The same test keeps breaking main. Flaky, or a real bug?
-
When someone needs an answer
Works on staging. Not for the customer.
Why a coworker
What the team knows leaves with the people who knew it.
Why a decision was made, which constraint mattered, what was tried before: when the engineer who knew it moves on, the next one rediscovers it from the code.
And the work itself is scattered. Requirements sit in Jira, code in GitHub, questions in Slack, test results somewhere else, and people carry the context from one to the next by hand.
Tools that sit next to one developer help that developer. Jigward belongs to the organization: anyone in it can ask Jigward, hand it work and read what it did.
Many ways in. One Context.
A question in Slack, an issue on Jira, a pull request to review or a Duty on a schedule: each one lands in the same Context, so Jigward starts from what it already knows about your project.
Ways in
-
Team chat
Mention it in the conversation.
-
Issue tracker
Assign it an issue.
-
Code review
Ask it to review a pull request.
-
Jigward app
Ask in Chat or use an Application.
-
Scheduled work
Set a Duty to run later.
Context
One lasting area of work, shared with Jigward.
- Repositories
- The code, database schema, APIs and dependencies.
- Project knowledge
- What earlier work established, with its sources.
What comes back
-
An answer or investigation
Findings the team can act on.
-
A draft pull request
A change for a person to review and merge.
-
Browser check results
What it checked and what happened.
-
An internal tool
A page the team can keep using.
The report goes back to the thread, issue, pull request or Chat where the work was requested.
Integrations
In the thread, on the issue, on the pull request.
Work reaches Jigward where it is given, and the report goes back there. To check the work, it reads your logs, opens your app and calls your APIs.
Where work comes in
What it checks with
A colleague with initiative.
Today, Jigward works through assigned Tasks and scheduled Duties. The goal is for it to notice what needs attention and take on work itself.
Decide a feature needs another QA pass. Find a bug, investigate it and prepare a fix without someone assigning every step. That independent initiative is a direction we are building toward.
See what is working and what is plannedRecently shipped
What changed in Jigward.
Changelog
-
Have Jigward build small tools for your team
Describe a tool your team needs, and Jigward builds it as a page with data of its own that you change by talking to it.
-
Schedule checks that run on their own
Ask Jigward to look at something once or on a rhythm, such as a channel every weekday morning, and hear back only when there is something to say.
-
Jigward sees where a pull request stands
Jigward reads whether a pull request is open, can be merged, was reviewed or was merged, so a Task or a scheduled check can follow it.
-
Jigward remembers what your team settles about the product
What a Task learns or a member explains in a Chat is kept for the Context with where it came from, so later work starts from it.
Questions
Before you bring Jigward onto the team.
More about access, models and control is in Before you connect.
Read Security & data before connecting a project.
Can we try Jigward with a TypeScript project?
Yes. Jigward works with repositories in any language, TypeScript included: it reads the code, answers questions about it, makes changes and opens draft pull requests.
It is tuned most deeply for JVM projects today — Java and Kotlin with Spring Boot, Gradle or Maven — where it also reads database schemas from migrations, API contracts and dependency trees. React, Angular and Vue front ends with npm, pnpm or Yarn are covered too. Tell us about your project when you request early access.
How much does Jigward cost?
Pricing has not been announced. There are no published plans or usage allowances yet. Request early access to discuss the work your team would give Jigward and what a useful pilot would look like.
Will everyone in our organization have access?
Yes. Jigward is a colleague for the whole organization. We do not plan to cap the number of members or connected integrations. Analysts, QA engineers and developers should all be able to work with the same Jigward.
Access is separate from how much work can run. Commercial execution allowances are still being defined. The Integrations page lists the systems and operations available today.
Are there limits on Contexts, Tasks, Duties or parallel work?
Jigward is in closed testing. Commercial limits for Contexts, the number of Tasks and Duties, and the number of Tasks that can run at once have not been finalized. No fixed commercial allowance or unlimited execution is promised.
When available Task execution capacity is occupied, additional Tasks wait in the queue. A Duty can give a Task when its instruction needs engineering work; that Task uses the same execution capacity as other Tasks.
Which models does Jigward use? Can we choose?
Jigward currently uses Anthropic Claude models through Amazon Bedrock: Sonnet, Opus and, where enabled, Fable. Jigward chooses the model for the work; members cannot choose a provider today.
The integrations, project knowledge and work history belong to Jigward. Support for customer-selected model providers is a planned direction.
Where does Jigward run? Can we host it ourselves?
Jigward is hosted on AWS and uses AgentCore for execution. Self-hosting is not offered today.
Deployment into a customer’s own AWS environment and access to private infrastructure are planned directions. Running on premises or on another cloud is not a supported option today.
What project information does the model see?
Relevant code, project knowledge, messages, logs and page content can be sent to Amazon Bedrock to do the work. Stored integration credentials use separate backend paths; that does not make the rest of the project anonymous.
The Security & data page explains organization access, credential handling, execution and model-specific retention, including the protections still being developed.
Does Jigward work without a new message from us?
Yes, through Duties. A standing instruction brings Jigward back once or on a schedule. It can check what changed and give a Task when that instruction needs engineering work. Jigward can create a Duty when a Chat or Task calls for coming back later.
The longer-term goal is independent initiative: noticing unattended work and deciding to investigate or run QA without a new assignment. Taking on new responsibilities on its own and participating in calls are not available today.
Does Jigward merge its own changes?
No. Jigward proposes code changes as draft pull requests on a branch of their own. The Task waits as Awaiting code review and is done once a person merges it. Jigward never resolves a conflict with the base branch on its own.
Can we try it?
Jigward is in closed testing. Request early access and describe your stack and the first piece of work you would hand over. The request starts a conversation; it does not create an account or reserve a place in a queue.
Startup programs
Volkoff LLC, the company behind Jigward, is a member of the NVIDIA Inception program.
Who’s behind it
Founder, Volkoff LLC · Senior Member, IEEE · Austin, Texas
Kiryl is a backend engineer who designs and builds JVM services on Java and Spring Boot, with a focus on service architecture and integration-heavy enterprise systems. Jigward goes deepest on that stack because it is the one he knows from the inside. Jigward is founder-led today, so early discovery conversations and pilots work directly with him.
Meet your next engineering coworker
Bring a question
from your own project.
See how Jigward can help your team understand the system and move the next task forward.
Jigward is in closed testing. Accounts are created by hand; sending a request does not create one.